remove rollover effect on profile search result

https://github.com/pH7Software/pH7-Social-Dating-CMS/wiki/How-to-ask-for-help

When we do search , it shows all profile images but i want to remove rollover effect on profile image as now when take mouse on it , its moving all the time.

@polynamaude Great work on the wiki page you created! :tada: I really appreciate your help on it!!!

@samit78
Please edit templates/themes/base/tpl/browse_user.inc.tpl, around line 30
https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/templates/themes/base/tpl/browse_user.inc.tpl#L30
And change
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, true) }}

to
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, false) }}

then, save the file and retry.
Hope this helps! Good luck

BTW @samit78
It would be also nice if you could Star this Github repo

Let me know if you need any further helps :)

Thanks its working but the image size became small , i madeit before size 125*125 but now it become small
Regards,
On Friday, February 22, 2019, 2:56:48 AM GMT+7, ♚ PH⑦ de Soria™♛<EMAIL_ADDRESS>wrote:

@samit78
Please edit templates/themes/base/tpl/browse_user.inc.tpl, around line 30
https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/templates/themes/base/tpl/browse_user.inc.tpl#L30
And change
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, true) }}
to
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, false) }}
then, save the file and retry.
Hope this helps! Good luck
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

When i added CSS on image.avatar width 125px and height 125px , it looks perfect on home page and search result page but on latest user : its stretching the image
Regards,
On Friday, February 22, 2019, 2:56:48 AM GMT+7, ♚ PH⑦ de Soria™♛<EMAIL_ADDRESS>wrote:

@samit78
Please edit templates/themes/base/tpl/browse_user.inc.tpl, around line 30
https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/templates/themes/base/tpl/browse_user.inc.tpl#L30
And change
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, true) }}
to
{{ $avatarDesign->get($user->username, $user->firstName, $user->sex, 64, false) }}
then, save the file and retry.
Hope this helps! Good luck
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@samit78 Have you looked with the page source option of your browser ?
It should give you some hint about what to change.


[Project] Rebuild IDMS Stack

Description
Rebuild a containerized version of the Knowledge Commons IDMS stack that is suitable for local development and deployment to production
Background
The current IDMS stack is composed of several services distributed across 3 EC2 instances (Miro diagram).
Main Services

Proxy

SATOSA

Registry

COmanage
Shibboleth (It might simplify things to replace this with SimpleSAMLphp?)
OpenLDAP

IDPOLR

SimpleSAMLphp

AWS RDS

Registry Database

These services have various configurations and plugins / modules / microservices specific to our setup. These customizations are not consistently in version control or synchronized between development and production. Many are out-of-date. We would like to change that.
There are currently two copies of this stack---dev and prod. We would like to move to a model with local development, and cloud-based staging and production. We might consider moving production and / or staging to a serverless solution, if that is more cost-effective than EC2.
Deliverables

All Commons IDMS code should exist in a single repository (this one).
The configurations, custom code, and plugins for services should be organized by directory. Eg:

├-/
  ├-metadata/
  | ├-dev-metadata.xml
  | ├-prod-metadata.xml
  |
  ├-SATOSA/
  | ├-hcdiscovery.yaml
  | ├-idp_metadata_attribute_store.yaml
  | ├-src/
  |   ├-hcdiscovery.py
  |   | ...
  |
  ├-COmanage/
  |  ├-Config/
  |  ├-Plugin/
  |  ├-webroot/
  ...

Each necessary service should exist in a container.
Where possible, containers should be based on standard production or development containers (eg. on Docker Hub).
The build process (eg. docker compose up or lando start) should build containers for each service and mount the Commons code and configurations appropriately. The containers should network together and operate in (local) dev, staging, and production environments.
Environment variables should control the build process to target each environment.
There should be a way to test the stack locally without WordPress (eg. static HTML pages with links for registering & logging-in test users, and reporting successful logins).
The stack should work with the containerized Commons WordPress stack (which will be developed in parallel).

Target Timeline

TBD

Responsibilities
Development Leads: Dimitris & Brian

Big Stages

[ ] Get IDMS stack working locally with development configuration and AWS RDS database
[ ] Local IDMS stack with local testing database
[ ] Works with multiple ( development / production ) configurations
[ ] Deploys to staging / production on AWS

Getting started

[ ] Figure out all of the essential services

Look at Miro boards, developer documentation. Verify that it is correct and complete.

[ ] Gather configuration files and other local customizations
[ ] Figure out how to use updated versions of the services (eg. SATOSA is currently way of out date)
[ ] ????
[ ] Get the local stack running

Resources:

HC IDMS Stack: https://miro.com/app/board/uXjVPH6GGBA=/
Identity Flow: https://miro.com/app/board/uXjVPNBgBWk=/
IDMS stack documentation: https://github.com/MESH-Research/hc-admin-docs-support/blob/main/documentation/developer/documentation/idms-stack.md
Humanities Commons Handbook: https://docs.google.com/document/d/1C13xaEnUPJ_dLUGQDbXv5Cr-E738pgg9dgU3enJyeEQ/edit#heading=h.uutzyhyfuu7s
COmanage documentation: https://spaces.at.internet2.edu/display/COmanage/Home


Voxel support HOST

Includes fmadd and slice 3D Kernel with testsuite changes

@snehaa8 Please also check on merge conflict

@snehaa8 @sampath1117 This PR already has fmadd and slice on HOST. Does this have all the test suite and function fixes, so we can issue this PR separate from HIP?

@snehaa8 master merge is done on my branch. Fixed 3-4 conflicts. Please pull my branch into yours to update.

Addressed all comments

fmadd and slice host merged as #173


System.Net.Sockets.SocketException on Azure

.Net Core 3.1
We are getting System.Net.Sockets.SocketException alot on our Production enviroment in our Azure apps service for windows.
The problem id is
System.Net.Sockets.SocketException at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw..
Call Stack
System.Net.Http.HttpRequestException:
   at System.Net.Http.ConnectHelper+<ConnectAsync>d__1.MoveNext (System.Net.Http, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
   at System.Net.Http.HttpConnectionPool+<ConnectAsync>d__52.MoveNext (System.Net.Http, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)

Application Insight Image:

Based on the stack trace, HttpClient was unable to connect to whatever service you were making a request against.
If you can provide the full message of the exception we may be able to provide a little more guidance, however this is usually an issue outside of HttpClient's control, within your network or within the web service you're using.


Properties are being copied from the previous note

Template:
---
tags:
  - daily-note
created: "{{date}} {{time}}"
---
## TO-DO List
## Daily Notes
---
Previous Note: [[{{previous_note_path}}|{{previous_note}}]]

Previous note:
---
tags:
  - daily-note
created: "2023-11-09 10:58"
---
Test
## TO-DO List
- [/] Test
## Daily Notes
---
Previous Note: [[2023-11-08]]

Newly created note:
---
tags:
  - daily-note
created: "2023-11-13 11:34"
---
created: "2023-11-09 10:58"
Test
## TO-DO List
- [/] Test
## Daily Notes
---
Previous Note: [[Daily Notes/2023-11-09.md|2023-11-09]]

Seems as though it is  incorrectly copying the created property over. IMO the plugin should just discard properties if present

I have never used properties so I didn't even know they existed. Currently obligator just copies every from the beginning of the file until the terminal heading. I'll look into how to fix that to be compatible with properties.

For the moment you can either manually delete the duplicate properties or not use them. But I'll get this fixed up soon.

@Jamalam360 Please try out release 3.8.0 and let me know if your issue is fixed. It should be.

Also, formatting with the date & time property works nicely with the template, see:

:+1: :+1: all working here, thank you for the quick turnaround and for the plugin!

👍 👍 all working here, thank you for the quick turnaround and for the plugin!

Glad you like it!


Datepicker overflows out of viewport

(lmk if this is intended behavior; I couldn’t find this in breaking changes)
Describe the bug
Datepicker doesn’t automatically get contained within the viewport anymore.
To Reproduce
Steps to reproduce the behavior:

Add a datepicker with no properties on the left- or rightmost side of the viewport:<Datepicker />

Ensure input-field is less wide than datepicker, for example:.react-datepicker-wrapper input {
  width: 20px
}

Click input-field to open datepicker

Expected behavior
In older* versions, the datepicker would automatically stay within the bounds of the viewport.
* Admittedly I was on a very old (v4) version before updating to v7 just now. I’m not sure what the default behavior was in v5 or 6.
Screenshots

Workaround
Give a value to the popperPlacement property:
<Datepicker popperPlacement="bottom-end" />

Note that only "popperPlacement="bottom" won’t keep the datepicker from overflowing horizontally.
Versions

react-datepicker 7.0.0
MacOS 14.5
Firefox 126 & Chrome 124

Additional comments
Great work on the new major release guys, I’m sorry to be the first to open a ticket (and so soon).

@rubenswieringa
react-datepicker was changed in some version of v4-v6 to rely on floating-ui instead of popper.
Because the detailed behavior can be controlled by the popperModifiers props,
Why not use shift?
https://floating-ui.com/docs/shift
If it doesn't work, please provide some sample code and I may be able to advise otherwise.

@yuki0410-dev That did the trick – thanks for the quick reply (and sorry for my late one). Will close this issue now.

@yuki0410-dev That did the trick – thanks for the quick reply (and sorry for my late one). Will close this issue now.

can you share the code you got this to work? this does not fix it for me:
import { shift, flip } from '@floating-ui/dom';
import { shift, flip } from '@floating-ui/dom';

// ...
popperModifiers={[shift(), flip({ padding: 5 })]}

am I using incorrectly?

In the end I just used popperPlacement="bottom-end" because my anchoring element was always at the right-most side of the screen, but my offset modifier might help you figure the syntax out:
<DatePicker
  popperPlacement="bottom-end"
  popperModifiers={[{ name: 'offset', fn: ({ y }) => ({ y: y + 5 }) }]}
/>

Also, have a look at the code sample for configuring the Popper/FloatingUI bits in the API docs:
https://reactdatepicker.com/#example-configure-floating-ui-properties

In case anybody else runs into a similar problem and needs to modify popper modifiers, I ran into a similar issue where I wanted the popper to not flip when it reaches the bounds of the screen. This is what I used:
<DatePicker
  popperPlacement="bottom-start"
  popperModifiers={[
    {
      name: 'remove-flip',
      fn: () => ({ reset: { placement: 'bottom-start', rects: true } })
    }
  ]}
/>


Fix encoding with verbatim turned on.

Current conditional made it so that Encode and not EncodeVerbatim is called for segmented sources where EncodeVerbatim was set to true.
true && !true => false, so you only the encode via f.Children.
This changeset makes it so the f.Children is not encoded at all for the case of a fragmented source.

My changes were triggered because the code as-is resulted in the segments being duplicated. Where file is an incoming mp4.
Taking the old ftyp and moov and adding those boxes to a new file, and adding in fragments and then encoding causes the boxes to be duplicate.
newFile := mp4.NewFile()
newFile.EncodeVerbatim = true
moofStartPos := file.Ftyp.Size() + file.Moov.Size()
newFile.AddChild(file.Ftyp, 0)
newFile.AddChild(file.Moov, 0)

for idx := range newFrags {
	  newFile.AddChild(newFrags[idx].Moof, moofStartPos)
	  newFile.AddChild(newFrags[idx].Mdat, 0)
	  moofStartPos += newFrags[idx].Moof.Size() + newFrags[idx].Mdat.Size()
}

newFile.Encode(os.Stdout)

Hmm. I fail to see that any boxes should be double if one just encodes the Children of the File. Which boxes become double for you?
There are anyway three ways of encoding fragmented files as I see it

encode all children with the data they have ("verbatim")
encode based on boxes in init and media segments "verbatim" without trun optimization
encode based on boxes in init and media segments and optimize trun
The two latter will skip top level boxes like skip, free, and mfra  so I think option 1 should be there also for fragmented files.
The main reason for a verbatim version of option 2 is to avoid optimizing trun. The reason I introduced it was to avoid
size changes. Maybe that second option should be called something else, or we could have three modes 🤔

Something like
type FragEncodeMode byte

const (
    EncodeModeAllChildren  = FragEncodeMod(0)  // verbatim encoding all top-level children
    EncodeModeTrunOptimize = FragEncodeMod(1) // current default mode with trun optimization
    EncodeModeNoOptimize   = FragEncodeMode(2) // Use EncodeVerbatim on MediaSegment
)

Would something like that make sense to you?

Yeah, that makes sense to me. Setting the level of optimization done is something that should definitely be possible.
I was trying to avoid any automatic behavior with the EncodeVerbatim option. I wanted it to output exactly what I added for a test I was doing.
The PR I submitted worked around the issue I observed because the segment had EncodeVerbatim called on it, but with the way it had been written, EncodeVerbatim wasn't called, so the trun optimizations were being applied.
Alternative #77, would appear to always call Encode so the behavior I wanted that was triggered via Verbatim wouldn't be called as it exists right?

I made PR #80 which should cover all three cases. I think that should cover your needs?

Closing in favor of alternative solution.


Fix hydra on release-17.09 by upgrading: 2017-09-14 -> 2017-10-26

Motivation for this change
Currently hydra fails to build on release-17.09 because nixUnstable got upgraded:
$ nix-build -A hydra
these derivations will be built:
  /nix/store/xii3bpaz4cfc5hgzk0iwqa8gr2x4in8c-hydra-2017-09-14.drv
building path(s) ‘/nix/store/al2c699sjrrsm6kpqklmlvm2siynqpm1-hydra-2017-09-14’
...
hydra-eval-jobs.cc:13:26: fatal error: common-opts.hh: No such file or directory
 #include "common-opts.hh"
                          ^
compilation terminated.

This is fixed by cherry-picking 286faa28341e53a8152e5170f8c57b26ea66378b on release-17.09 which upgrades hydra to the latest HEAD which can build against the latest nixUnstable (https://github.com/NixOS/hydra/commit/2cdc84f34f4de647dd89c5ef503782a3a48ff623).
@orivej ping.
Things done
nix-build nixos/tests/hydra.nix succeeds.

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

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

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thank you. Release maintainers don't like cherry picks without the reference to the original commit (git cherry-pick -x), so I had to add it.

I think we should add hydra to the release job.

@orivej TIL about cherry-pick -x. Thanks.


Clip animation without between-frame artifacts

A followup on https://twitter.com/ChromiumDev/status/845402027362521088
I added 2 raf-s to figure out the refresh rate of the device in order to accomodate varying refresh rates. It's wrapped in a requestIdleCallback and promisified to give the thread breathing room for accurate detection.
The animation is then defined per frame and uses animation-timing-function: step-end to only render the those needed.
In theory, this approach should not cause mid-frame artifacts, generates ~1/10th of the frames for usual ~200-ish durations and is a bit fancier. Should be easier processing wise as well.

Remade this pull request to fix the CLA errors.

Should be truer to the original now. Interested to hear your take on it.

poke
Any chance you'll have some spare time to review soon-ish  :)?
Beefing up my portfolio for a position, and an accepted PR from the Surminator considering web perf. would be a_muy_zing.

All looks good except the indentation :D

Derp. There we go. I'm useless without ESlint.

Nice job! 🎉 🎉 🎉 🎉

Yäy.


Multiple fixes for IE8 and lower. Fixes for &count=1 returning 0 images from API.

Hi,
I used this script on a client's site and hit a couple of errors.
Instagram endpoint returning 0 images, when requesting 1
It seems like the API endpoint of Instagram sometimes returns 0 results when doing a request for 1. I've added code to query minimum two images, and filter them out in the response parser.
IE8
IE8 didn't work when using templating
In the templating system this was caused by the splice.call function adding only 1 parameter. IE8 and below requires an additional parameter for deleteCount (http://www.to-string.com/2012/05/29/fixing-splice-in-older-versions-of-internet-explorer-8-and-olders/). This was added. It also required the array to be a native JS array. Reworked the code to pass an prepared array.
IE8 didn't work when using sorting
The bind function isn't implemented in IE < 9. Added a polyfill to handle this.

Hey @espentveit! I wasn't able to merge this PR directly, but v1.4 should close any remaining IE8 bugs!
Thank you for your contribution!


Fix CSRF error handler test.

As noted in #200 and #243, the CSRF error handler does not work as documented. However, the test passed because it only checked for the error reason in the response and the index.html template included form.errors.

#264 deprecated error_handler. Use Flask's error handling system with @app.errorhandler(CsrfError). As a temporary measure, custom handlers decorated with @csrf.error_handler allow both return and raise.


Testing models and Seeds make sure they are working.

Seed file runs but tables are not being seeded.

Realized some model relationships were not correct. Code needed to be refactored.
Needed to use a many to many relationship with books and genre. This required use of a junction table, which also required its own seeding.


[UX] PowerToys Run is de-selecting text field after each keystroke

Environment
Windows build number: 10.0.18363.836
PowerToys version: 0.18.0
PowerToy module for which you are reporting the bug (if applicable): PowerToys Run

Steps to reproduce
Press Alt+Space, start to write Spotify, or Chrome, or any other thing (including math operations).
Expected behavior
I should be able to keep writing the name even if the first result is selected. Pressing enter and the up/down arrow keys should still work without having to tab to the results list.
Actual behavior
Every keystroke refreshes the result list, selects the first one and prevents me to keep typing. I always have to shift+tab back to it. Rinse and repeat for every single keystroke.

@besknighter do you have a screenshot to help us understand it better? This sounds related to #2259

@bestknighter do you have a screenshot to help us understand it better? This sounds related to #2259

It could be. Here, I made two screen recordings. Pay attention to the text cursor. Every time it disappears it's not me. When it reappears it's me pressing shift+tab. Sometimes I managed to do two key presses before it deselecting the field. If it's not yet that clear, I can do it again using the virtual keyboard.

Different from #2259, mine is always in this state. I don't even need to right click it to make it happen.

Ok, update: I tried right clicking just like in that other issue and it actually made it go back to normal. Right clicking once more made the bug come back.

I am having the exact same issue. I don't know what additional information would help you to find the issue, so just let me know if you need anything.

I canrepport the same issue 👍

I'm having the same issue. Right-clicking makes no appreciable difference for me.

If this is the same as #2259, we have a hotfix.

I don't know how this could help, but while trying to get Wox plugins to work I restarted PowerToys a couple times, and also toggled the Run module off and on a couple times. After that, for some reason this issue doesn't appear anymore, even after a system reboot. Maybe some of the guys above can test this further.

We just released 0.18.1 which should have this fix included in it.  If it doesn't fix it, please comment and we'll reopen.


DRAFT: DO NOT MERGE >>Support for API docs

adds template and plugin
produces mdx file for standard petstore boilerplate

x STUCK: at linking to file {which file // just name? not extensions of file?} need to research/or help around using mdx in Docusaurus

Closing this in favour of pure Open RPC API


Chapter-wise bibliography works, but cross-referencing fails

Bug description
What I would like to do
I tried to use chapter-wise bibliographies using the Quarto extension/filter section-bibliographies, which is working.
However, when using the section-bibliographies filter, the cross-referencing fails. For example, instead of "Figure 1", there is<EMAIL_ADDRESS>What I have tried
The problem persists both in PDF (pdflatex, lualatex, xelatex) and HTML formats, and also both in individual documents and books. If citeproc: true is set, then the literature cross-referencing does not produce correct references either.
Note that I had filed an issue at quarto-dev, but on second thoughts I feel this issue is better filed here.
Screenshot of the bug

Steps to reproduce
---
title: "Sectionwise bibliography works, cross-referencing fails"
bibliography: references.bib

filters:
  - section-bibliographies
reference-section-title: References
citeproc: false

format:  pdf
---

# Part1

Lorem ipsum.
Read @knuth84.
See @fig-mtcars.

```{r}
#| label: fig-mtcars
#| fig-cap: Some caption
data(mtcars)
plot(mtcars)
```

# Part2

Also read @knuth84.

Here's the content of references.bib:
@article{knuth84,
  author = {Knuth, Donald E.},
  title = {Literate Programming},
  year = {1984},
  issue_date = {May 1984},
  publisher = {Oxford University Press, Inc.},
  address = {USA},
  volume = {27},
  number = {2},
  issn = {0010-4620},
  url = {https://doi.org/10.1093/comjnl/27.2.97},
  doi = {10.1093/comjnl/27.2.97},
  journal = {Comput. J.},
  month = may,
  pages = {97–111},
  numpages = {15}
}

Expected behavior
I would like to have a bibliography for each chapter without missing cross-referencing figures etc.
Actual behavior
When using the filter section-bibliographies, the cross-referencing breaks.
My environment

RStudio: 2023.06.0
OS: MacOS Sonoma 14.6.1

Quarto check output
Quarto 1.6.8
[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.2.0: OK
Dart Sass version 1.70.0: OK
Deno version 1.41.0: OK
Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
Version: 1.6.8
Path: /Applications/quarto/bin
[✓] Checking tools....................OK
TinyTeX: v2024.07.03
Chromium: 869685
[✓] Checking LaTeX....................OK
Using: TinyTex
Path: /Users/sebastiansaueruser/Library/TinyTeX/bin/universal-darwin
Version: 2024
[✓] Checking basic markdown render....OK
[✓] Checking Python 3 installation....OK
Version: 3.11.5
Path: /usr/local/bin/python3
Jupyter: 5.4.0
Kernels: python3
[✓] Checking Jupyter engine render....OK
[✓] Checking R installation...........OK
Version: 4.2.1
Path: /Library/Frameworks/R.framework/Resources
LibPaths:
- /Users/sebastiansaueruser/Rlibs
- /Library/Frameworks/R.framework/Versions/4.2/Resources/library
knitr: 1.48
rmarkdown: 2.28
[✓] Checking Knitr engine render......OK
Relevance
I think chapter-wise bibliography is an important feature, as large publishers demand chapter-wise bibliography. So thanks a lot for this feature!

Thanks for the report, I agree that this is the right place to file.
I don't think it's a problem with the filter, but the documentation is outdated and should clarify the order in which this filter and Quarto-internal filters need to be run. I will have to look that up, Quarto has changed a good bit in the last version.

@tarleb I'll be happy to help you with this, ofc!


[Bug]: L40 GPU deepseek-v2 fp8  cuda graph error;  Using --enforce-eager can run properly.

Your current environment

The output of `python collect_env.py`
Collecting environment 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: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: Could not collect
CMake version: version 3.30.3
Libc version: glibc-2.31

Python version: 3.11.2 (main, Jul 23 2024, 17:09:09) [GCC 10.2.1 20210110] (64-bit runtime)
Python platform: Linux-5.4.143.bsk.8-amd64-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 12.4.131
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA L40
GPU 1: NVIDIA L40
GPU 2: NVIDIA L40
GPU 3: NVIDIA L40
GPU 4: NVIDIA L40
GPU 5: NVIDIA L40
GPU 6: NVIDIA L40
GPU 7: NVIDIA L40

Nvidia driver version: Could not collect
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
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
Byte Order:                      Little Endian
Address sizes:                   52 bits physical, 57 bits virtual
CPU(s):                          180
On-line CPU(s) list:             0-179
Thread(s) per core:              2
Core(s) per socket:              45
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           143
Model name:                      Intel(R) Xeon(R) Platinum 8457C
Stepping:                        8
CPU MHz:                         2599.583
BogoMIPS:                        5199.16
Hypervisor vendor:               KVM
Virtualization type:             full
L1d cache:                       4.2 MiB
L1i cache:                       2.8 MiB
L2 cache:                        180 MiB
L3 cache:                        195 MiB
NUMA node0 CPU(s):               0-89
NUMA node1 CPU(s):               90-179
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          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
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Mitigation; TSX disabled
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16 wbnoinvd arat avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid cldemote movdiri movdir64b md_clear arch_capabilities

Versions of relevant libraries:
[pip3] byted-torch==2.4.0.post1
[pip3] flashinfer==0.1.6+cu124torch2.4
[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] pyzmq==26.2.0
[pip3] torch==2.4.0
[pip3] torchao==0.5.0
[pip3] torchaudio==2.4.0+cu124
[pip3] torchvision==0.19.0
[pip3] transformers==4.44.2
[pip3] triton==3.0.0
[pip3] zmq==0.0.0
[conda] Could not collect
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.6.1.post2@3724d5f6b59d9859e5b47c047535bb8edc124eab
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    NIC0    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NODE    NODE    NODE    SYS     SYS     SYS     SYS     SYS     2-89    0               N/A
GPU1    NODE     X      NODE    NODE    SYS     SYS     SYS     SYS     SYS     2-89    0               N/A
GPU2    NODE    NODE     X      NODE    SYS     SYS     SYS     SYS     SYS     2-89    0               N/A
GPU3    NODE    NODE    NODE     X      SYS     SYS     SYS     SYS     SYS     2-89    0               N/A
GPU4    SYS     SYS     SYS     SYS      X      NODE    NODE    NODE    SYS     92-177  1               N/A
GPU5    SYS     SYS     SYS     SYS     NODE     X      NODE    NODE    SYS     92-177  1               N/A
GPU6    SYS     SYS     SYS     SYS     NODE    NODE     X      NODE    SYS     92-177  1               N/A
GPU7    SYS     SYS     SYS     SYS     NODE    NODE    NODE     X      SYS     92-177  1               N/A
NIC0    SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X

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

NIC Legend:

  NIC0: mlx5_0

Model Input Dumps
python3 -m vllm.entrypoints.openai.api_server --model  neuralmagic/DeepSeek-Coder-V2-Instruct-FP8  --served-model-name dsv2 --trust-remote-code --tensor-parallel-size 8 --max-model-len 8192 --port $PORT0 --gpu-memory-utilization 0.99 --kv-cache-dtype fp8 >> deepseek_v2.log 2>&1
🐛 Describe the bug
Process SpawnProcess-1:
Traceback (most recent call last):
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/worker/model_runner.py", line 1679, in capture
output_hidden_or_intermediate_states = self.model(
^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/models/deepseek_v2.py", line 504, in forward
hidden_states = self.model(input_ids, positions, kv_caches,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/models/deepseek_v2.py", line 461, in forward
hidden_states, residual = layer(positions, hidden_states,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/models/deepseek_v2.py", line 401, in forward
hidden_states = self.mlp(hidden_states)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/models/deepseek_v2.py", line 148, in forward
final_hidden_states = self.experts(
^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
return forward_call(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/layers/fused_moe/layer.py", line 469, in forward
final_hidden_states = self.quant_method.apply(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/layers/quantization/fp8.py", line 496, in apply
return fused_experts(x,
^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/layers/fused_moe/fused_moe.py", line 553, in fused_experts
invoke_fused_moe_kernel(curr_hidden_states,
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vllm/model_executor/layers/fused_moe/fused_moe.py", line 258, in invoke_fused_moe_kernel
fused_moe_kernel[grid](
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/triton/runtime/jit.py", line 345, in
return lambda *args, **kwargs: self.run(grid=grid, warmup=False, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/triton/runtime/jit.py", line 691, in run
kernel.run(grid_0, grid_1, grid_2, stream, kernel.function, kernel.packed_metadata, launch_metadata,
File "/home/tiger/.pyenv/versions/3.11.2/lib/python3.11/site-packages/triton/backends/nvidia/driver.py", line 365, in call
self.launch(*args, **kwargs)
RuntimeError: Triton Error [CUDA]: operation failed due to a previous error during capture
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.

To adapt to the L40, I modified the shared memory in https://github.com/vllm-project/vllm/blob/main/csrc/moe_align_block_size_kernels.cu to global memory and used cudaMalloc. Could this modification have affected the capture of the CUDA graph?
void moe_align_block_size(torch::Tensor topk_ids, int64_t num_experts,
107                           int64_t block_size, torch::Tensor sorted_token_ids,
108                           torch::Tensor experts_ids,
109                           torch::Tensor num_tokens_post_pad) {
110   const cudaStream_t stream = at::cuda::getCurrentCUDAStream();
111   VLLM_DISPATCH_INTEGRAL_TYPES(
112       topk_ids.scalar_type(), "moe_align_block_size_kernel", [&] {
113         // calc needed amount of shared mem for `tokens_cnts` and `cumsum`
114         // tensors
115 //         const int32_t shared_mem =
116 //             ((num_experts + 1) * num_experts + (num_experts + 1)) *
117 //             sizeof(int32_t);
118
119         const int32_t mem_tokens_cnts =
120             ((num_experts + 1) * num_experts) * sizeof(int32_t);
121         const int32_t mem_cumsum =
122             (num_experts + 1) * sizeof(int32_t);
123
124         // allocate global memory
125         int32_t* tokens_cnts;
126         int32_t* cumsum;
127         cudaMalloc(&tokens_cnts, mem_tokens_cnts);
128         cudaMalloc(&cumsum, mem_cumsum);
129
130
131         // set dynamic shared mem
132         auto kernel = vllm::moe_align_block_size_kernel<scalar_t>;
133 //         AT_CUDA_CHECK(VLLM_DevFuncAttribute_SET_MaxDynamicSharedMemorySize(
134 //             (void*)kernel, shared_mem));
135         kernel<<<1, num_experts, 0, stream>>>(
136             topk_ids.data_ptr<scalar_t>(), sorted_token_ids.data_ptr<int32_t>(),
137             experts_ids.data_ptr<int32_t>(),
138             num_tokens_post_pad.data_ptr<int32_t>(), num_experts, block_size,
139             topk_ids.numel(),tokens_cnts, cumsum);
140
141         // free global memory
142         cudaFree(tokens_cnts);

Thanks for reporting, I was able to reproduce on an L40 system with vllm==0.6.1.post2 with CUDA_LAUNCH_BLOCKING=1 vllm serve neuralmagic/DeepSeek-Coder-V2-Instruct-FP8 --trust-remote-code --tensor-parallel-size 8.
I'm not sure what the cause is yet, but it is clearly an issue with moe_align_block_size. It fails with and without cudagraphs for me. We will continue to look into it.

Thanks for reporting, I was able to reproduce on an L40 system with vllm==0.6.1.post2 with CUDA_LAUNCH_BLOCKING=1 vllm serve neuralmagic/DeepSeek-Coder-V2-Instruct-FP8 --trust-remote-code --tensor-parallel-size 8.
I'm not sure what the cause is yet, but it is clearly an issue with moe_align_block_size. It fails with and without cudagraphs for me. We will continue to look into it.

@mgoin Hi，I've pinpointed this line:
const int32_t shared_mem = ((num_experts + 1) * num_experts + (num_experts + 1)) * sizeof(int32_t)

In deepseek-v2, here the size of shared_mem ((161*160+161) * 4 = 101.25kb) exceeds the maximum shared_mem of L40 SM.

Thanks for reporting, I was able to reproduce on an L40 system with vllm==0.6.1.post2 with CUDA_LAUNCH_BLOCKING=1 vllm serve neuralmagic/DeepSeek-Coder-V2-Instruct-FP8 --trust-remote-code --tensor-parallel-size 8.
I'm not sure what the cause is yet, but it is clearly an issue with moe_align_block_size. It fails with and without cudagraphs for me. We will continue to look into it.

Hi @mgoin Is there a plan to fix this issue soon?

@fengyang95 how did this resolve? Was there a fix landed?

@fengyang95 how did this resolve? Was there a fix landed?

@mgoin To avoid the issue of insufficient L40 shared memory, I changed the data type of tokens_cnt to uint16, and then it worked.

I'm facing the same problem using L20. so you change the cuda file and build vllm from source? @fengyang95


[Feature] Module to add state independent normal scale

Description
For continuous action spaces, it is not uncommon to define normal policies with state independent variance. For example, the original PPO paper does so for the MuJoCo trainings.
This PR proposes o add a module that handles this situation.
Motivation and Context
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here.
You can use the syntax close #15213 if this solves the issue #15213

[ ] I have raised an issue to propose this change (required for new features and bug fixes)

Types of changes
What types of changes does your code introduce? Remove all that do not apply:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds core functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (update in the documentation)
[ ] Example (update in the folder of examples)

Checklist
Go over all the following points, and put an x in all the boxes that apply.
If you are unsure about any of these, don't hesitate to ask. We are here to help!

[x] I have read the CONTRIBUTION guide (required)
[ ] My change requires a change to the documentation.
[ ] I have updated the tests accordingly (required for a bug fix or a new feature).
[ ] I have updated the documentation accordingly.

Nice feature!
Would it make sense to integrate that in NormalParamExtractor under a trainable_bias or argument in the constructor (named to be chosen)? It seems like a lot of code is the same as NormalParamExtractor and the functionality would blend in nicely. Happy to hear your thoughts about this.
Tests are missing btw

Failures seem unrelated to this PR so I'm happy to merge it


kube3d: 4.2.0 -> 4.3.0

Motivation for this change
Replaces #115868
Bump kube3d to 4.3.0
Also

Bump k3sVersion to match official release
Set buildFlagsArray in bash
Add changelog

Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

Result of nixpkgs-review pr 115937 run on x86_64-linux 1

1 package built:

kube3d


track all attempts to filter EVT files

Currently attempts to filter EVT files that don't produce focused particles for whatever reason are not tracked. This makes it hard to reason whether an EVT file was been processed yet or not. Realtime analysis is most affected since in the worst case you will reprocess a completely out of focus EVT file every analysis iteration, and if there are many such files this can cause a backlog in realtime analysis.
Every attempt to filter an EVT file should produce an OPP entry in the database, and these entries can be filtered out in downstream steps.

v1.1.0 tracks all filtering attempts.


Changes git_data_dir  param

The parameter for custom git dir has changed. See config template on https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template

Yuck, that's a disgusting syntax for a config file (I guess it's a ruby thing?), but it looks like it's correct, so I'll merge this in and tag a new minor version bump.


🔌 Plugin: Consolidate Azure DevOps Scaffolder Actions

🔖 Summary
Currently there are two packages that seems to be moderately unmaintained - they both look to have changes merged in the last month - that the Community is using for Azure DevOps Scaffolder Actions. Should these be consolidated into a single plugin/package in the Community Plugins repo in the existing Azure DevOps workspace?
🌐 Project website (if applicable)

https://github.com/Parfuemerie-Douglas/scaffolder-backend-module-azure-pipelines
https://github.com/Parfuemerie-Douglas/scaffolder-backend-module-azure-repositories

✌ Context
Discord Thread: https://discord.com/channels/687207715902193673/1154845617756065932
Request to move one of the packages: https://github.com/Parfuemerie-Douglas/scaffolder-backend-module-azure-pipelines/issues/30
PR to move one to here: https://github.com/backstage/community-plugins/pull/1358
👀 Have you spent some time to check if this plugin request has been raised before?

[X] I checked and didn't find similar issue

✍ Are you willing to maintain the plugin?

[X] I understand the responsibilities as a Plugin Maintainer Governance & will maintain the plugin

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

As the owner of the current Azure DevOps workspace in this repo I'm open to helping maintain these if they are moved but that would mostly be helping with reviews and version bumping things. I would expect the general community to contribute new features, fix bug, or do any other migration work.

@antoniobergas and @Phiph - would like your feedback on this as you have a better idea of the current state of things. Ideally I'd like to have all the actions in one plugin/package this just makes things a lot easier to take care of.

Hi @awanlin, thanks a lot for starting to move this topic. Recently, I had to work with repos and make changes via PR using the scaffolder (essentially the Azure DevOps repos actions package).
To make it work (at least in our internal instance), I needed to change the Git implementation because the auth was not working properly for us; some extra headers were needed, and I think the Git implementation from Backstage packages was deprecated. Not sure if this is a specific case or something that can happen to more people.
Also, I think one of the packages is using fetch and the other azure-devops-node-api. I would suggest unifying them and using azure-devops-node-api in both.
Regarding the authorization, I recently got it working with the new backend system by creating a customExtension. I’m not 100% sure if the injection of the integrations dependency is correct, but it works!
Hope this info helps with the migration!

Thanks for starting this conversation, @awanlin! I'd be happy to help maintain the Azure DevOps actions in the community, as I use them daily.
Like Antonio, I map the actions using the createBackendModule function. Both packages work well with the registered Service Principal and the user tokens from the scaffolder.
However, I had to uninstall the azure-pipelines package due to some dependency issues between the plugin packages and the backend.
@antoniobergas For this first action the PR I've submitted should work for both our needs. I checked your code and noticed you're using the DefaultAzureDevOpsCredentialsProvider, which is the same approach proposed in the PR.
We should be able to unify most of the actions to use  azure-devops-node-api thanks to the v13 release that includes PipelinesInterfaces. For the permitAzurePipeline action, we might need to use fetch, as the pipelinepermissions API isn't in the package yet.

Hi, I have not heard back from the main author(s), I'd like to give them a month to do my due diligence. Based on that the week on the 28th I'll review the active PR end to end. I am thinking that I'll do an early review in the next few days to see if there are any high level changes needed.

Hi, I think at this point we have done our due diligence and we'll move forward with this. 👍

Does it makes sense also to consolidate the integration part of azure to make it work for azure devops, azure resources(management), and msGraph?
I think It would be nice to centralise the credentials resolves in one place and be able to re use it from integration later on

Hi @Sarabadu, I would say that's worthy of it's own issue and not related to the topic of the Scaffolder actions. This issue perhaps makes more sense for this conversation: https://github.com/backstage/backstage/issues/21158

Closing as the initial module has been created and others can be now added as needed


The Terminal crashes when dragging the window to a secondary monitor

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.476]
Windows Terminal Version: 0.6.2951.0

Any other software?: NO

Steps to reproduce
when i open the terminal on my surface laptop it works fine but when i try to drag the windows to another monitor, the application crashes.
i have a surface laptop hooked up to surface dock which is connected to 2 monitors and the behavior appears on both of them
Expected behavior
the terminal stays open and might change the size and the resolution depending on the monitor
Actual behavior
the terminal window crashes and all the tabs in the windows get closed

Thanks for the report! This is actually something that's already being tracked by another issue:
/dup #3303
Please make sure to search when filing new issues. Thanks!


Cannot read property 'length' of undefined, Ember 3.5

I have jQuery disabled, seeing this:
(node:94431) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'length' of undefined
    at compress.then.compressed (/Users/mgardner/labs-zola/node_modules/broccoli-concat-analyser/lib/summarize.js:54:29)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
(node:94431) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:94431) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Woops, seems like a duplicate of https://github.com/stefanpenner/broccoli-concat-analyser/issues/32. Will try the fixes listed there... not sure if this is something new or a dependency issue.

Pretty sure this is a problem in the upstream broccoli-concat-analyser, but will try to investigate this...

It seems to die with it uglifies moment/lib

Hm, yes, could indeed be related to failing uglification...
@allthesignals Is there a way to reproduce this easily? Is your project in the open, or have some minimal reproduction? moment/lib comes from ember-moment?

Hi @simonihmig, thanks for the response. The repo is open, I'm seeing the behavior here: https://github.com/NYCPlanning/labs-zola
I also have trouble getting broccoli-concat-analyser to generate the dot folder:
$ broccoli-concat-analyser .
⠹ processing...TypeError: Cannot convert undefined or null to object

Ah, thanks Matt, that was really helpful. Also nice to see you are developing this app in the open! 😄
I debugged this, and uncovered quite a few different issues: 😬

#9
#10
https://github.com/stefanpenner/broccoli-concat-analyser/issues/39
https://github.com/stefanpenner/broccoli-concat-analyser/issues/40

The root issue is indeed that ugify-es was failing to minify your vendor.js with some error during AST-traversal. It did work with some older version of it though (which I still had in my yarn.lock). Proof:

Will walk through the issues asap...

I fixed most things, and published v0.0.4. With that version I could successfully get the stats output in your app! 🎉
I hope it works for you as well. Closing this for now, feel free to reopen if it doesn't!

Thank you so much @simonihmig! You are lightning fast! My treemap works great. Now back to tracking down oversized assets...
I think my only separate issue is here, but I'm at least seeing the file sizes match up:


crypto/tls: Failure to handshake when ClientHello lacks Point Formats Extension

What version of Go are you using (go version)?

$ go version
go version go1.18.4 linux/amd64

Does this issue reproduce with the latest release?
Yes; it is present on master.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cipherboy/.cache/go-build"
GOENV="/home/cipherboy/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/cipherboy/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/cipherboy/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3518916122=/tmp/go-build -gno-record-gcc-switches"

What did you do?
This was discovered during testing between a partner and Hashicorp. This partner's TLSv1.2-only (third-party) client refused to connect to a Vault Go TLS server.
Analysis of the Client Hello sent by this program showed that it sent the supported groups extension (expecting to enable forward-secrecy via ECDHE), but elided the (RFC 8422) Client Hello Point Format extension. This client was configured to only send ECDHE algorithms (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384), so the handshake failed with a cipher suite mismatch handshake exception. However, this client supports the uncompressed point format and so its expected the handshake should succeed.
In replicating this behavior against other popular open TLS servers (NSS, GnuTLS, and OpenSSL), Go was alone in refusing the handshake. All the others would accept the handshake and use uncompressed point format for ECHDE negotiation.
Per RFC 8422 Section 5.1.2:

RFC 4492 specified that if this extension is missing, it means that only the uncompressed point format is supported, so interoperability with implementations that support the uncompressed format should work with or without the extension.

The reference to RFC 8422 and RFC 4492 comes via the Go source, implying that this behavior should've been supported by Go.
In particular, in this helper function (refactored from the pre-Go 1.14 code which had the same bug):
https://github.com/golang/go/blob/424814615491c604e6a0945f33e5a7b779dc2be5/src/crypto/tls/handshake_server.go#L306-L326
we see that the value for supportsPointFormat is strictly computed from the extension if it is non-empty and present. However, if the extension is elided  altogether, it retains its default value of false. This is incorrect per the referenced RFCs.
This is reproducible via the following Go program:
package main

import (
	"flag"
	"log"
	"net/http"
)

func main() {
	cert := flag.String("cert", "localhost.crt", "Server certificate in PEM format")
	key := flag.String("key", "localhost.key", "Server certificate's corresponding key, in PEM format")
	addr := flag.String("addr", ":443", "Server's listening address")

	flag.Parse()

	log.Printf("Running with cert: %v / key: %v", *cert, *key)

	http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
		w.Header().Set("Content-Type", "text/plain")
		w.Write([]byte("go-server@tlsfuzzer\n"))
		log.Println("Replied to request")
	})

	err := http.ListenAndServeTLS(*addr, *cert, *key, nil)
	if err != nil {
		log.Fatalf("Got error while serving (on %v): %v", *addr, err)
	}
}

With the packet stream (see attached pcap from tlsfuzzer scenario above):
tlsfuzzer-repo-pcapng.zip

$ go run ./main.go -addr ":8443" &
$ echo "1603000099010000950303000000000000000000000000000000000000000000000000000000000000000000000ac009c013c02bc02f00ff01000062000a0006000400170100000d00280026080b080a08090806080508040601050104010301020101010603050304030303020308080807003200280026080b080a08090806080508040601050104010301020101010603050304030303020308080807" | xxd -r -p | nc localhost 8443 | xxd -p
15030300020228

(the hex result decodes to alert / Handshake Failure).
What did you expect to see?
Handshake success.
What did you see instead?
Handshake failure.
Possible Fixes
As I understand it, there's two ways of fixing this: we could use presence of Supported Groups (+ECDHE suites) as sufficient evidence towards ECDHE support for uncompressed point formats (easy) -- or prefer to negotiate a non-ECDHE cipher ahead of a ECDHE-cipher.

In the former, case this looks like changing the helper above to define supportsPointFormat := len(supportedPoints) == 0, to allow an unspecified extension to accept ECDHE negotiation automatically. This would fix the value for hs.ecdheOk and allow ECDHE to succeed unconditionally. The downside of this approach is that we could choose a ECDHE cipher when the client doesn't actually support Uncompressed point format, which I think is rarely the case (especially given both RFC 8422 and 4492 above). The client would then fail the handshake, and could probably provide justification to fix the client.

n.b.: during unmarshalling, we already check that the wire supportedPoints length is non-empty in the extension, so the len check is correct.

Otherwise, we could also condition it around having only ECDHE (and DHE? Hmmmm... ) cipher suites in the first case (i.e., something like len(supportedPoints) == 0 && len(nonECDHEClientHelloCipherSuites) == 0. The downside of this approach is that we could elide forward secrecy in the scenario when DHE isn't negotiated (impossible with a Go server AFAICT?) and the client was hoping for ECDHE. Instead, we'd end up on a legacy suite without Forward Secrecy, which is definitely less than ideal.

IMO, I'd prefer the first approach.
Either way, I'm happy to write a patch with test cases for this scenario. Let me know what the thoughts are w.r.t. approach.

Duplicate of #49126


explorer farms

implement explorer farms

https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1021

There is weird behavior, all data in table not returned after i removed the filter.

https://github.com/threefoldtech/tfgrid-sdk-ts/assets/54944491/58d490f9-b5d5-4ee3-9af4-4ed85d4a4c37

I think the  bar with x icon inside it too big

Here, the table keeps loading forever despite i added wrong filter.

If the stellar address is empty, can we show a "-" instead of blank?

Also, if the farm details pop-up was closed in any way other than using the x icon, it won't be opened again, neither in this farm or any other farm.
screen-capture.webm

The table is showing only 50 farms while there's 4k+ farms on devnet.

The 50 limit is implemented from the gridproxy

Currently The farm name search will only return the farm if its exact name is entered and if a sub-string of its name is entered it will return No data available is this the expected behavior for this filter? to search only by the exact name of the farm?
Screencast.from.22-11-<IP_ADDRESS>.webm

This is the same behaviour as in the nodes page filter

Why the toast appears ? the filtration is invalid already
Screencast from 11-22-2023 03:20:56 PM.webm

there shouldn't be arrow with the name
what do u think ?

sometimes people want to sort by farm name, it is an additional helpful feature

Here u're handling already while fetching data.
But shouldn't there be a time out like in my case i changed network to offline. ( for example show msg and reload button as in dedicated nodes and explorer farms)
Screencast from 11-21-2023 10:45:12 AM.webm

I think there's sth wrong with the filter as it searches within this specific page instead of searching in all farms. Maybe we can create a new request instead of filtering in the existing farms?

[ ]  Farm name might include "-" or "_"  so I suggest to update the filter accordingly.

[ ] Total IPs filter doesn't work

[ ] Also, there is only 1 pricing policy, so I don't think we need to filter by it.

[ ]  I think there's sth wrong with the filter as it searches within this specific page instead of searching in all farms. Maybe we can create a new request instead of filtering in the existing farms?

[x]   Farm name might include "-" or "_"  so I suggest to update the filter accordingly.

[x]  Total IPs filter doesn't work

[x]  Also, there is only 1 pricing policy, so I don't think we need to filter by it.

filter searches all farms and a request is made for every valid search , it is working fine for me
 here

[ ] It shows no farms but I have a farm with the same name.

[ ] Also, when I set the filters then go to another page then return back to farms, filters won't reset.

node-filter.webm

@zaelgohary the filter is working fine for zee-farm

thanks for the comment, I have added a beforeUnMount action to clear filter inputs.


change non recurring DFS

I changed the implementation to non-recurring DFS.
This will do the following well.

This implementation does not use recursion, so it does not cause a stack overflow even if the number of nodes is large.
#21

One problem with this approach is that if more than one input receives a single output, it will be stored in a duplicate calculation order list.
I'm currently working on a solution to this problem, but have not been able to improve it.

Hi! Many thanks for the PR :)  Currently a bit busy but I'll have a look and get back to you soon :+1:

Close because this PR has little merit and is getting old.

I'm sorry you feel that way! I already had a quick look at the changes and I like the overall direction, but to be honest I haven't yet had time to take a proper look at it due to several irl things that have got me quite busy for the past few months.
I've been merging other PRs since, but the scope of this is a bit larger so I wanted to take proper time to review it. My overall feeling was that this change is useful to other users and I was inclined to merge it :+1:

Sorry, I didn't word it right.
I realized that the infinite loop countermeasure can be done by just adding a little bit of writing to the current state using a recursive function. On top of that, I have decided to build another minimal PR because there is little advantage to a NON RECURRING DFS.
I thank @setzer22 for building a great library and of course you can prioritize your day job😊👍.


feat(AutoEnsureMiddleware): add ensureProperties property option

Codecov Report

Merging #41 (77f349b) into main (0c44696) will decrease coverage by 32.00%.
The diff coverage is 48.38%.

@@             Coverage Diff              @@
##              main      #41       +/-   ##
============================================
- Coverage   100.00%   68.00%   -32.00%
============================================
  Files            2        2
  Lines           58      100       +42
  Branches         2       26       +24
============================================
+ Hits            58       68       +10
- Misses           0       24       +24
- Partials         0        8        +8

Impacted Files
Coverage Δ

...ckages/auto-ensure/src/lib/AutoEnsureMiddleware.ts
67.67% <48.38%> (-32.33%)
:arrow_down:

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 0c44696...77f349b. Read the comment docs.


Fix asset->coin param migration in withdrawal api

asset is the legacy param name; now the API expects coin instead.

Thanks @knaperek


IOS Version

Is there any Plans for Something Similar for IOS.

Unfortunately, no. We had started building something similar for iOS and Windows but active development as stopped.
Though I would urge someone to try. The same design principles that Proteus is built on should work on iOS too.


New release

Could we please get a new release with all the new changes since v0.0.2?
Thanks
@dbutenhof

Sure ... call this "the September release" (v0.0.3)


video streaming

Send the video data from sensors to delphi. There has been success using sockets to get the data from OpenCV on the seers to delphi. Otherwise, this can be done via http

no longer needed


Update SubWallet information

Update logo and information for SubWallet project

@saltict : can you please sign the CLA? 🙏🏻

@saltict : can you please sign the CLA? 🙏🏻

Hello @sacha-l, I signed the CLA last week, and everything seems to be ok and just needs a review:

Do I need to sign it one more time?


Support iOS 18's dark icon

iOS 18 and iPadOS 18 now support dark-themed app icons. I would like to enable a dark-themed icon in DevToys.
References:

https://developer.apple.com/design/human-interface-guidelines/app-icons#iOS-iPadOS

I've created new icons. 2af398ebef360099753193a8ebf1ec424aa47911
However, Swift Playgrounds currently does not support dark and tinted icons. I have to build DevToys.swiftpm with Xcode 16 for now when I upload it to the App Store Connect.


Compare to pipeline created timestamp while using before/after filter

pipeline_started and pipeline_finished can be 0 for various reasons and therefor is unreliable for timestamp filters. Using pipeline_created might be the better option anyway.

Thanks. As I try improve my own label handling, when do we choose bug vs regression?


Relative Values Plot is broken

_ Is refactor
x Is new feature
_ Concerns documentation

Description of suggestion or shortcoming:

Caused by this check: https://github.com/quantified-uncertainty/squiggle/blob/eec3d21ce1b2b0ab67a981a26f8865eae97aa57c/packages/components/src/widgets/PlotWidget/RelativeValuesGridChart/index.tsx#L66


Typo in pip command

According to the the official PyPI documentation from Todoist, the package name is todoist-python. Correcting it here.

Thanks @mbbroberg appreciated the help.


A typo in "14. Controlling concurrency with flow"

A } is missing before else:
    if (growZone == NoGrowZone) {
        plantRepository.tryUpdateRecentPlantsCache()
     else {
        .tryUpdateRecentPlantsForGrowZoneCache(growZone)
     }

Thank you, I've corrected the text in the internal codelab source document and it will be visible soon, once we publish a new version on the website.

Thank you, I've corrected the text in the internal codelab source document and it will be visible soon, once we publish a new version on the website.


Pester Tests for Developers

[ ] Fail on ::new( since it is not supported in PS3. But allow Certificates & aztoken because I'm not rewriting those yet.

More soon as I remember them.

this is a breeze with the newest PSSA. Lemme see if the latest has still problems with formatting


[Bug]: AssertionError: Error in memory profiling. Initial free memory<PHONE_NUMBER>6, current free memory<PHONE_NUMBER>6. This happens when the GPU memory was not properly cleaned up before initializing the vLLM instance. [rank0]:[W1010 16:28:18.581149478 CudaIPCTypes.cpp:16] Producer process has been terminated before all shared CUDA tensors released. See Note [Sharing CUDA tensors] ERROR 10-10 16:28:20 api_server.py:188] RPCServer process died before responding to readiness probe

Your current environment

The same code is working on runpod using 2xA100 XSM gpus. while when i try using 2 H100 gpu it showing weird error. the environment is same.

!vllm serve Imran1/Qwen2.5-72B-Instruct-FP8 \
    --tensor-parallel-size 2 \
    --dtype auto \
    --api-key token-abc123 \
    --max-model-len 2000 \
    --kv-cache-dtype auto \
    --gpu_memory_utilization 0.9 \

vllm version: 0.6.2
aiohttp: 3.10.9
einops: 0.8.0
fastapi: 0.115.0
filelock: 3.13.1
gguf: 0.9.1
importlib-metadata: 4.6.4
lm-format-enforcer: 0.10.6
mistral-common: 1.4.4
msgspec: 0.18.6
numpy: 1.26.3
nvidia-ml-py: 12.560.30
openai: 1.51.2
outlines: 0.0.46
partial-json-parser: <IP_ADDRESS>.post4
pillow: 10.4.0
prometheus-client: 0.21.0
prometheus-fastapi-instrumentator: 7.0.0
protobuf: 5.28.2
psutil: 6.0.0
py-cpuinfo: 9.0.0
pydantic: 2.9.2
pyyaml: 6.0.2
pyzmq: 24.0.1
ray: 2.37.0
requests: 2.32.3
sentencepiece: 0.2.0
tiktoken: 0.7.0
tokenizers: 0.20.0
torch: 2.4.0+cu121
torchvision: 0.19.0+cu121
tqdm: 4.66.5
transformers: 4.45.2
typing-extensions: 4.12.2
uvicorn: 0.31.1
xformers: 0.0.27.post2

CUDA Version: 12.1

Model Input Dumps
INFO 10-10 16:27:39 api_server.py:495] vLLM API server version 0.6.1.post1
INFO 10-10 16:27:39 api_server.py:496] args: Namespace(model_tag='Imran1/Qwen2.5-72B-Instruct-FP8', config='', host=None, port=8000, uvicorn_log_level='info', allow_credentials=False, allowed_origins=['*'], allowed_methods=['*'], allowed_headers=['*'], api_key='token-abc123', lora_modules=None, prompt_adapters=None, chat_template=None, response_role='assistant', ssl_keyfile=None, ssl_certfile=None, ssl_ca_certs=None, ssl_cert_reqs=0, root_path=None, middleware=[], return_tokens_as_token_ids=False, disable_frontend_multiprocessing=False, enable_auto_tool_choice=False, tool_call_parser=None, model='Imran1/Qwen2.5-72B-Instruct-FP8', tokenizer=None, skip_tokenizer_init=False, revision=None, code_revision=None, tokenizer_revision=None, tokenizer_mode='auto', trust_remote_code=False, download_dir=None, load_format='auto', config_format='auto', dtype='auto', kv_cache_dtype='auto', quantization_param_path=None, max_model_len=2000, guided_decoding_backend='outlines', distributed_executor_backend=None, worker_use_ray=False, pipeline_parallel_size=1, tensor_parallel_size=2, max_parallel_loading_workers=None, ray_workers_use_nsight=False, block_size=16, enable_prefix_caching=False, disable_sliding_window=False, use_v2_block_manager=False, num_lookahead_slots=0, seed=0, swap_space=4, cpu_offload_gb=0, gpu_memory_utilization=0.9, num_gpu_blocks_override=None, max_num_batched_tokens=None, max_num_seqs=256, max_logprobs=20, disable_log_stats=False, quantization=None, rope_scaling=None, rope_theta=None, enforce_eager=False, max_context_len_to_capture=None, max_seq_len_to_capture=8192, disable_custom_all_reduce=False, tokenizer_pool_size=0, tokenizer_pool_type='ray', tokenizer_pool_extra_config=None, limit_mm_per_prompt=None, enable_lora=False, max_loras=1, max_lora_rank=16, lora_extra_vocab_size=256, lora_dtype='auto', long_lora_scaling_factors=None, max_cpu_loras=None, fully_sharded_loras=False, enable_prompt_adapter=False, max_prompt_adapters=1, max_prompt_adapter_token=0, device='auto', num_scheduler_steps=1, scheduler_delay_factor=0.0, enable_chunked_prefill=None, speculative_model=None, speculative_model_quantization=None, num_speculative_tokens=None, speculative_draft_tensor_parallel_size=None, speculative_max_model_len=None, speculative_disable_by_batch_size=None, ngram_prompt_lookup_max=None, ngram_prompt_lookup_min=None, spec_decoding_acceptance_method='rejection_sampler', typical_acceptance_sampler_posterior_threshold=None, typical_acceptance_sampler_posterior_alpha=None, disable_logprobs_during_spec_decoding=None, model_loader_extra_config=None, ignore_patterns=[], preemption_mode=None, served_model_name=None, qlora_adapter_name_or_path=None, otlp_traces_endpoint=None, collect_detailed_traces=None, disable_async_output_proc=False, override_neuron_config=None, disable_log_requests=False, max_log_len=None, dispatch_function=<function serve at 0x7fb02f57b9a0>)
INFO 10-10 16:27:40 api_server.py:162] Multiprocessing frontend to use ipc:///tmp/7f842e34-72e6-4e63-a126-8c60b13b2ca1 for RPC Path.
INFO 10-10 16:27:40 api_server.py:178] Started engine process with PID 6179
INFO 10-10 16:27:45 config.py:904] Defaulting to use mp for distributed inference
INFO 10-10 16:27:45 llm_engine.py:223] Initializing an LLM engine (v0.6.1.post1) with config: model='Imran1/Qwen2.5-72B-Instruct-FP8', speculative_config=None, tokenizer='Imran1/Qwen2.5-72B-Instruct-FP8', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, rope_scaling=None, rope_theta=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.bfloat16, max_seq_len=2000, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=2, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=compressed-tensors, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=Imran1/Qwen2.5-72B-Instruct-FP8, use_v2_block_manager=False, num_scheduler_steps=1, enable_prefix_caching=False, use_async_output_proc=True)
INFO 10-10 16:27:46 custom_cache_manager.py:17] Setting Triton cache manager to: vllm.triton_utils.custom_cache_manager:CustomCacheManager
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:47 multiproc_worker_utils.py:215] Worker ready; awaiting tasks
INFO 10-10 16:27:48 utils.py:981] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:48 utils.py:981] Found nccl from library libnccl.so.2
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:48 pynccl.py:63] vLLM is using nccl==2.20.5
INFO 10-10 16:27:48 pynccl.py:63] vLLM is using nccl==2.20.5
INFO 10-10 16:27:52 custom_all_reduce_utils.py:242] reading GPU P2P access cache from /home/work/.cache/vllm/gpu_p2p_access_cache_for_0,1.json
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:52 custom_all_reduce_utils.py:242] reading GPU P2P access cache from /home/work/.cache/vllm/gpu_p2p_access_cache_for_0,1.json
INFO 10-10 16:27:52 shm_broadcast.py:235] vLLM message queue communication handle: Handle(connect_ip='<IP_ADDRESS>', local_reader_ranks=[1], buffer=<vllm.distributed.device_communicators.shm_broadcast.ShmRingBuffer object at 0x7f788a008f40>, local_subscribe_port=59323, remote_subscribe_port=None)
INFO 10-10 16:27:52 model_runner.py:997] Starting to load model Imran1/Qwen2.5-72B-Instruct-FP8...
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:52 model_runner.py:997] Starting to load model Imran1/Qwen2.5-72B-Instruct-FP8...
(VllmWorkerProcess pid=6185) INFO 10-10 16:27:59 weight_utils.py:242] Using model weights format ['*.safetensors']
INFO 10-10 16:27:59 weight_utils.py:242] Using model weights format ['*.safetensors']
Loading safetensors checkpoint shards:   0% Completed | 0/16 [00:00<?, ?it/s]
Loading safetensors checkpoint shards:   6% Completed | 1/16 [00:00<00:12,  1.18it/s]
Loading safetensors checkpoint shards:  12% Completed | 2/16 [00:01<00:11,  1.20it/s]
Loading safetensors checkpoint shards:  19% Completed | 3/16 [00:01<00:07,  1.66it/s]
Loading safetensors checkpoint shards:  25% Completed | 4/16 [00:02<00:08,  1.43it/s]
Loading safetensors checkpoint shards:  31% Completed | 5/16 [00:03<00:08,  1.29it/s]
Loading safetensors checkpoint shards:  38% Completed | 6/16 [00:04<00:08,  1.24it/s]
Loading safetensors checkpoint shards:  44% Completed | 7/16 [00:05<00:07,  1.24it/s]
Loading safetensors checkpoint shards:  50% Completed | 8/16 [00:06<00:06,  1.25it/s]
Loading safetensors checkpoint shards:  56% Completed | 9/16 [00:07<00:05,  1.24it/s]
Loading safetensors checkpoint shards:  62% Completed | 10/16 [00:07<00:04,  1.22it/s]
Loading safetensors checkpoint shards:  69% Completed | 11/16 [00:08<00:04,  1.21it/s]
Loading safetensors checkpoint shards:  75% Completed | 12/16 [00:09<00:03,  1.23it/s]
Loading safetensors checkpoint shards:  81% Completed | 13/16 [00:10<00:02,  1.34it/s]
Loading safetensors checkpoint shards:  88% Completed | 14/16 [00:10<00:01,  1.28it/s]
Loading safetensors checkpoint shards:  94% Completed | 15/16 [00:11<00:00,  1.26it/s]
(VllmWorkerProcess pid=6185) INFO 10-10 16:28:12 model_runner.py:1008] Loading model weights took 35.1591 GB
Loading safetensors checkpoint shards: 100% Completed | 16/16 [00:12<00:00,  1.27it/s]
Loading safetensors checkpoint shards: 100% Completed | 16/16 [00:12<00:00,  1.27it/s]

INFO 10-10 16:28:13 model_runner.py:1008] Loading model weights took 35.1591 GB
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226] Exception in worker VllmWorkerProcess while processing method determine_num_available_blocks: Error in memory profiling. Initial free memory<PHONE_NUMBER>6, current free memory<PHONE_NUMBER>6. This happens when the GPU memory was not properly cleaned up before initializing the vLLM instance., Traceback (most recent call last):
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]   File "/home/work/.local/lib/python3.10/site-packages/vllm/executor/multiproc_worker_utils.py", line 223, in _run_worker_process
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]     output = executor(*args, **kwargs)
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]   File "/home/work/.local/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]     return func(*args, **kwargs)
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]   File "/home/work/.local/lib/python3.10/site-packages/vllm/worker/worker.py", line 232, in determine_num_available_blocks
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]     assert peak_memory > 0, (
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226] AssertionError: Error in memory profiling. Initial free memory<PHONE_NUMBER>6, current free memory<PHONE_NUMBER>6. This happens when the GPU memory was not properly cleaned up before initializing the vLLM instance.
(VllmWorkerProcess pid=6185) ERROR 10-10 16:28:16 multiproc_worker_utils.py:226]
Process SpawnProcess-1:
ERROR 10-10 16:28:17 multiproc_worker_utils.py:120] Worker VllmWorkerProcess pid 6185 died, exit code: -15
INFO 10-10 16:28:17 multiproc_worker_utils.py:123] Killing local vLLM worker processes
Traceback (most recent call last):
  File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/work/.local/lib/python3.10/site-packages/vllm/entrypoints/openai/rpc/server.py", line 236, in run_rpc_server
    server = AsyncEngineRPCServer(async_engine_args, usage_context, rpc_path)
  File "/home/work/.local/lib/python3.10/site-packages/vllm/entrypoints/openai/rpc/server.py", line 34, in __init__
    self.engine = AsyncLLMEngine.from_engine_args(
  File "/home/work/.local/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 573, in from_engine_args
    engine = cls(
  File "/home/work/.local/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 473, in __init__
    self.engine = self._engine_class(*args, **kwargs)
  File "/home/work/.local/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 257, in __init__
    super().__init__(*args, **kwargs)
  File "/home/work/.local/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 331, in __init__
    self._initialize_kv_caches()
  File "/home/work/.local/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 460, in _initialize_kv_caches
    self.model_executor.determine_num_available_blocks())
  File "/home/work/.local/lib/python3.10/site-packages/vllm/executor/distributed_gpu_executor.py", line 39, in determine_num_available_blocks
    num_blocks = self._run_workers("determine_num_available_blocks", )
  File "/home/work/.local/lib/python3.10/site-packages/vllm/executor/multiproc_gpu_executor.py", line 199, in _run_workers
    driver_worker_output = driver_worker_method(*args, **kwargs)
  File "/home/work/.local/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
    return func(*args, **kwargs)
  File "/home/work/.local/lib/python3.10/site-packages/vllm/worker/worker.py", line 232, in determine_num_available_blocks
    assert peak_memory > 0, (
AssertionError: Error in memory profiling. Initial free memory<PHONE_NUMBER>6, current free memory<PHONE_NUMBER>6. This happens when the GPU memory was not properly cleaned up before initializing the vLLM instance.
[rank0]:[W1010 16:28:18.581149478 CudaIPCTypes.cpp:16] Producer process has been terminated before all shared CUDA tensors released. See Note [Sharing CUDA tensors]
ERROR 10-10 16:28:20 api_server.py:188] RPCServer process died before responding to readiness probe

🐛 Describe the bug
AssertionError: Error in memory profiling. Initial free memory<PHONE_NUMBER>6, current free memory<PHONE_NUMBER>6. This happens when the GPU memory was not properly cleaned up before initializing the vLLM instance.
[rank0]:[W1010 16:28:18.581149478 CudaIPCTypes.cpp:16] Producer process has been terminated before all shared CUDA tensors released. See Note [Sharing CUDA tensors]
ERROR 10-10 16:28:20 api_server.py:188] RPCServer process died before responding to readiness probe

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.

The Same like your question，my model is work success on A30 but not work on A10

The Same like your question. The bug fired at some certain machines.


fix: publish tag on ghcr rather than Docker Hub

Even less images on the Docker Hub

Why not directly to ECR ?


Orchestrator:prepare not finding all artifacts, despite them being available and published

Describe the bug
While trying to build a dev pool, prepare fetches a list of all artifacts to be deployed from our npm registry. All other CICD operations, e.g. validate and build, are able to retrieve the artifact without a problem. However, the prepare step does not find two of our artifacts, and it is always the same two. I have tried fixing a version in my release definition, to no avail. I have also tried using a release config file, but that also did not help out here.
To Reproduce
Steps to reproduce the behavior:
For me, it's as simple as trying to run sfp orchestrator:prepare -f config/sfdx-pool/dev/dev-pool-def-1.json -v devhub --npmrcpath $(npmrc.secureFilePath) --loglevel trace in our pipeline.
What I get is the following log
Fetching src-env-specific-pre using npm pack<EMAIL_ADDRESS>Fetching utility using npm pack<EMAIL_ADDRESS>Fetching salescloud using npm pack<EMAIL_ADDRESS>Artifact  for salescloud missing in NPM Registry provided, This might result in deployment failures
Fetching salescloudb2b using npm pack<EMAIL_ADDRESS>Fetching servicecloud using npm pack<EMAIL_ADDRESS>Fetching marketing-consent using npm pack<EMAIL_ADDRESS>Fetching experiencecloud using npm pack<EMAIL_ADDRESS>Fetching analytics using npm pack<EMAIL_ADDRESS>Fetching src-vlocity-management using npm pack<EMAIL_ADDRESS>Fetching vlocitycustomer using npm pack<EMAIL_ADDRESS>Artifact  for vlocitycustomer missing in NPM Registry provided, This might result in deployment failures
Fetching customerui using npm pack<EMAIL_ADDRESS>Fetching src-access-management using npm pack<EMAIL_ADDRESS>
It's always the same two artifacts that cannot be found, although I have checked multiple times that yes, they do in fact exist, and out build pipeline also successfully deployed both of them to our UAT instance just half an hour ago. The problem is exclusive to prepare as far as I can tell.
As the other artifacts can be found, this also seems to be not an issue with npm authentication. I would expect nothing to be found in that way.
Expected behavior
All artifacts should be found and installed.
Platform Details (please complete the following information):
This is using the latest release of the sfpowerscripts repository container. (25.5.3-7028186930)
Additional context
I get that this is probably more of an npm issue than an sfp one. If I can give any more information or get pointers on what to check additionally, I would greatly appreciate it.

I think i have updated the error handling to provide more details when this happens as part of another issue as part of the next release. I will double check it
Meanwhile can you try npm pack command directly?
Also what's rhe repository provider you are targeting? Could it be an issue with scope?

We are using Artifacts inside Azure Devops to save our artifacts. Regarding using npm pack directly I will have to check how to directly authenticate, as this part of the pipeline was configured by another colleague. Some more outputs in the logs would be a great start!

Hi @dschibster Can you please check one thing for me. Is the version from the screenshot really the latest version/tag for the package? You should know that we use a different background process for the prepare job to identify the package version. We use git to search for the last tag for the package. So is salescloud 0.1.0-192 really the latest version and have you really exactly this artifacts in the registry? It can happen with wrong job settings (wrong cloning strategy or git fetch tags settings) that not all tags are found and thus a wrong reference to the artifacts is created.

I have one update!
It seems like the console output is wrong, or that prepare has a fallback, because following the dev pool creation, although the artifacts were not found they do in fact get installed and working. The installation errors I was facing came from malconfigured packages.

@dschibster New clear log messages are added and fixed in Feb2024 versions. Please do let me know if it is helping you.


Whether z-index can be defined by itself

If there are 2 dialog boxes，want to change z-index.

There coudn't be two swal2 dialogs at the same time by design.
In order to set z-index to a swal2 modal:
.swal2-modal {
  z-index: 100;
}


Add '@_requiresConcreteImplementation' and use it

This PR adds a new attribute, @_requiresConcreteImplementation, and adopts it for the one protocol requirement in RandomNumberGenerator.
Motivation
The motivation for adding this facility is a scenario as follows—

Protocol P has a requirement func frobnicate(_: Int).
Protocol P can offer a protocol extension method func frobnicate<T>(_: T) which is implemented by calling frobnicate(_: Int).

Currently, the type checker regards the protocol extension method as a valid witness for the protocol requirement, causing a recursive default implementation. Users implementing P are misled, thinking that they have implemented all necessary protocol requirements, only to be faced with a runtime error.
A concrete example of this problem exists in the standard library: RandomNumberGenerator has a requirement next() -> UInt64 which is unwittingly witnessed by a protocol extension method next<T: FixedWidthInteger & UnsignedInteger>() -> T. Conforming types that do not supply a concrete implementation of the non-generic method will compile but cause crashes at runtime.
It should not be necessary to name two semantically identical methods differently just to work around this problem. As the core team stated in apple/swift-evolution#912:

The issue with accidental infinite recursion occurs in other APIs and can't be fixed so easily in those cases, so ideally we'd find a way of enhancing the language to help users avoid this situation in a more general way.

See also: https://forums.swift.org/t/how-to-best-fix-this-old-random-api-bug/34526

Solution
The current solution takes inspiration from existing attributes such as @_nonoverride and @_implements. The new attribute does what it says on the tin. It can be used on any (non-associatedtype) protocol requirement so that Sema rejects an implementation in a protocol extension as an acceptable witness.
Unfortunately, it appears that we are running out of numbers to serialize attributes. I have had to twiddle with DeclTypeRecordNodes.def in order to make room; there's now room for a handful more attributes, but this is clearly not sustainable—nor am I certain about the implications of renumbering all decl type record nodes for attributes in this way.

There is an additional (aspirational) goal for this solution which is interesting to consider:
It is permitted to add a requirement to a resilient protocol, but only if a default implementation is also provided. One may envision scenarios where a default implementation for such a requirement is possible for all conforming types but greatly suboptimal.
It would be ideal to support scenarios where the default implementation can be made available for all existing clients (i.e., for resiliency purposes), but nonetheless to require all new conformances going forward to provide concrete implementations. The @_requiresConcreteImplementation attribute could enable this possibility.
I am not nimble enough in the inner workings of the compiler but suspect that the implementation presented here would not be sufficient to enable this use case as-is. It would be necessary to record a default implementation as a valid witness for runtime purposes but invalid at compile time conformance checking. Something like this must already be present in the codebase for availability annotations.

@DougGregor because I don't actually know what I'm doing while rooting around Sema. @airspeedswift as he's been involved with the motivating issue as regards to the standard library.
I'll also tag @jens-bc here as he raised the issue regarding RandomNumberGenerator on GitHub. Also, @belkadan I know you're not in the same role anymore, but I wonder if you might be able to comment on any thoughts related to the utility of something like this for resilient libraries.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 1ca7dc3c292b91ac08d450f9b15d011fa0923d9e

Build failed
Swift Test Linux Platform
Git Sha - 1ca7dc3c292b91ac08d450f9b15d011fa0923d9e

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 1ca7dc3c292b91ac08d450f9b15d011fa0923d9e

Build failed
Swift Test OS X Platform
Git Sha - 1ca7dc3c292b91ac08d450f9b15d011fa0923d9e

Third time's the charm.
@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 530dde59c59652c24fcdb7bbf4e66c6e32e682ef

Build failed
Swift Test OS X Platform
Git Sha - 530dde59c59652c24fcdb7bbf4e66c6e32e682ef

Personally, I'm pretty against this as a general-purpose solution. There's no reason (in a perfect world) why every concrete type would have to avoid getting its implementation from a protocol extension. I'd say it's the implementation who bears this responsibility, because it is a valid witness to a requirement in the protocol it is extending. So I'd prefer an attribute on the implementation that says "this implementation must not satisfy a requirement with the same full name in the protocol it's extending" (and have it be a warning, not an error, so as not to break source compatibility). That's effectively similar to the (conservative) infinite recursion checking we already have—"the body of this method may call the requirement in an unguarded way, so they better not be the same"—which makes me feel a lot better about it being a reasonable fix to the problem.
None of these solutions solve the general problem of "two requirements and you must implement at least one of them", but that's just gonna be hard regardless.

As a side note, it should be fine to renumber all the serialization node numbers as long as you bump SWIFTMODULE_VERSION_MINOR. Those were more important when we thought we were going to have a stable binary format.

So I'd prefer an attribute on the implementation that says "this implementation must not satisfy a requirement with the same full name in the protocol it's extending" (and have it be a warning, not an error, so as not to break source compatibility).

More like an @_implementsNothing type of annotation? Yeah, that's an alternative I thought about. I think in practice it'll work out to be fairly similarly, and I almost wonder if it could be worked into the existing code paths for @_implements.
What swayed me more towards the approach given here, I guess, was considering the case of complex protocol hierarchies:
It's quite legitimate for a refining protocol to provide a default implementation for a requirement of a less refined protocol. It's also legitimate to make use of default implementations guaranteed by less refined protocols in building up a more refined one. It would seem to me that authors of protocol extension methods can more easily reason about their code if they don't have to worry about some refining protocol inadvertently throwing a wrench into things in this way, and seems consonant with Swift's general approach of placing such decisions in the hands of those vending the APIs (c.f. open versus public).

Unrelated OS X test failure.

It's also legitimate to make use of default implementations guaranteed by less refined protocols in building up a more refined one.

I don't understand this point. Default implementations are not guaranteed, and neither of our designs would change that.

It would seem to me that authors of protocol extension methods can more easily reason about their code if they don't have to worry about some refining protocol inadvertently throwing a wrench into things in this way, and seems consonant with Swift's general approach of placing such decisions in the hands of those vending the APIs (c.f. open versus public).

I don't agree. If a superclass wants to invoke a method and be sure a subclass doesn't override it, the other method has to not be open; if a protocol extension method wants to invoke another method and be sure it's not going through the requirement, that other method has to not be named the same as the requirement. Again, though, I don't see what this has to do with whether the attribute belongs on the requirement vs. the default implementation; in neither case do we have a protocol extension method trying to invoke another protocol extension method.

Since we have control over where the attribute is applied, we can still have enforcement be an error; we would only break source compatibility if we applied it somewhere that rendered existing working conformances an error. In this case, no existing code would actually break, because even though conforming RandomNumberGenerator types might compile, they would crash instantly on usage.

It seems nice to me to design the feature so that it can be applied to other protocols where existing implementations might be only partially broken rather than completely broken.

I don't understand this point. Default implementations are not guaranteed, and neither of our designs would change that.

I should rephrase that more carefully: an implementation is guaranteed, and that could be the default one.

Again, though, I don't see what this has to do with whether the attribute belongs on the requirement vs. the default implementation; in neither case do we have a protocol extension method trying to invoke another protocol extension method.

I think I have described the scenario poorly. Let me do so by way of example; it's going to take a beat to come up with a good one, so perhaps it's not a common enough scenario to be concerned about solving. I'll circle back to this.

This has been a while and, I think, has been superseded by the cleverly devised workaround of @_alwaysEmitIntoClient @available(unavailable...) default implementations. I'll close.


Please choose a software license (not a Creative Commons license)

My concern is that I'm not clear what the attribution requirement means for software.
I would go with an MIT license for this particular project:
https://opensource.org/licenses/MIT
Note that Creative Commons does not recommend using their licenses for software:
https://wiki.creativecommons.org/index.php/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F

We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses made available by the Free Software Foundation or listed as “open source” by the Open Source Initiative.

Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. Many software licenses also address patent rights, which are important to software but may not be applicable to other copyrightable works. Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses.

Thanks for pointing this out! We'll switch the license to something more sensible.

https://github.com/lunametrics/youtube-google-analytics/commit/54a47168c401d35405754fa65a7d05792d200940


Remove and optimize dependencies to speedup compilation

This PR removes the longest-to-compile dependencies:

[x] Remove the zstd crate (required by the zip crate), but uncompress the mini-dashboard release.
[x] Replace the git2 crate with the gitcl one, but we require the git CLI to compile and retrieve the git info.

[ ] Make sure the Docker build image has the git CLI.

[x] Move to the latest version of Lindera, where @dureuill reworked the build scripts to avoid downloading and decompressing dictionaries at every build.

[x] Update the CONTRIBUTING.md to inform the users to set the LINDERA_CACHE env var.

before-cargo-timing.html.zip
after-cargo-timing.html.zip

The lindera work landed so the sole remaining item is

Make sure the Docker build image has the git CLI.


Warn log when using Andes client

Description
Following error is printed every time we invoke a client application written using the Andes client.
[2018-04-23 16:31:17,727] WARN  {org.wso2.andes.common.QpidProperties} - Unable to find resource qpidversion.properties from classloader

Fixed with https://github.com/wso2/andes/pull/970


Milestone 2 submission

Complete and submit the Milestone 2 assignment as per the instructions on Canvas

Wrote up milestone 2.
Submitted on Canvas.
[t:25]