vscode:corrected the base path from which to pull the extensions

Should fix https://github.com/rycee/home-manager/issues/888

Thanks a lot! Rebased to master in 595150be86639cd1e41c9eba1cf02dc503d10c23. I hope it'll work fine for mac users now.


Feat/suffix for events

Description
Suffix parsing for events
Type of change
Please delete options that are not relevant.

[x] New feature

How Has This Been Tested?
I verified the feature correctness in Splunk
Checklist

[x] My commit message is conventional
[x] I have run pre-commit on all files before creating the PR
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have checked my code and corrected any misspellings

Codecov Report

Merging #192 (77489e9) into develop (747945b) will decrease coverage by 0.38%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##           develop     #192      +/-   ##
===========================================
- Coverage    49.50%   49.11%   -0.39%
===========================================
  Files           22       22
  Lines         1422     1417       -5
===========================================
- Hits           704      696       -8
- Misses         718      721       +3

Impacted Files
Coverage Δ

...lunk_connect_for_snmp_poller/manager/hec_sender.py
65.45% <60.00%> (-0.62%)
:arrow_down:

...ect_for_snmp_poller/manager/static/mib_enricher.py
95.31% <100.00%> (-4.69%)
: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 747945b...77489e9. Read the comment docs.

:tada: This PR is included in version 1.5.0-develop.44 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


⬆ chore: Bump Playwright to 1.40.1

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

new-dawn

PR #1046   👈

This stack of pull requests is managed by Graphite.


Vue.js option tag re-rendering issue when :value attribute is null

Vue version
3.4.19
Link to minimal reproduction
https://codepen.io/thisishak/pen/GRebBMp
Steps to reproduce
You must use a macos chrome browser.
Use the interval function to modify variables that are not related to the select element.
click the select element to open the list of options.
What is expected?
just keep the open option list ui
What is actually happening?
option list ui blinks
System Info
macos ventura 13.4
chrome 121.0.6167.184(arm64)

Any additional comments?
No response

https://github.com/vuejs/core/assets/56523406/31efea79-00ac-4dd9-872f-342e50d35f0d
https://github.com/vuejs/core/assets/56523406/0bdb6f49-632d-4791-a3dd-cf4e577bfc2b

+ v-memo="[firstSelect]"

Or use Vue Single File Components (.vue).


Add a top-level tests script

This PR adds a top-level testing script and polishes the interface_tests testing script.
This testing script can then be used before pushing/merging PRs through a CI.

Ideas:

We could use the same naming conventions everywhere—now /intro has ./test.sh, interface_tests/ has run.sh, /compiler has test_evaluation_scripts.sh, and benchmarks have run_all_benchmarks.sh :-)

Also, we could place these echo statements in the test files themselves (the scripts that have different names) and skip the cd by making them callable from everywhere with something like cd $(dirname $0)

(cc @dkarnikis to help us here)

Just merged, to unblock and also help with the PR bot, but we should fix:-)


Lite CLI for running containers on Remote Docker Engine Without Installing Docker Engine Locally

A recent blog post on the AWS blog — AWS and Docker collaborate to simplify the developer experience — demonstrated the new Docker Engine ECS integration as a simple CLI route to running containers remotely on Amazon ECS.
One benefit of running containers remotely is that users on devices that cannot run Docker natively (iPad users, users on old / legacy Windows machines) can launch and run containers in the cloud and access them via web browser UIs.
It would be useful if a "lite" Docker CLI were available that would allow users to run docker ecs ... commands, which launch and manage remote containers, without also having to install the full Docker Desktop application. This would allow users who cannot run Docker Desktop or a local Docker Engine to launch and run containers remotely using a relevant subset of the Docker CLI commands.
At the moment, other partial workarounds are available. For example, to run containers on Digital Ocean, the doctl CLI can be used to launch a Digital Ocean Docker droplet. If the user has ssh available, they can then ssh in to the droplet and start their container from within the remote environment.

The CLI is separate from Engine or Desktop, though usually included in most distributions of them. https://github.com/docker/cli/
The Linux binaries are published as "docker-ce-cli" packages in our apt/yum repos.
Mac builds: https://docs.docker.com/engine/install/binaries/#install-client-binaries-on-macos
You can unofficially find Windows builds here: https://github.com/StefanScherer/docker-cli-builder/tags

@binman-docker Thanks for the pointers. I think it could still be useful if there were an easily found official simple CLI. A lot of applications are bundled in containers now, and just because folk are happy using the apps that run in headless containers via browser accessed http/HTML UIs doesn't mean they are developers who are happy finding and installing things from repos.
The CLI step is often a blocker, and in the AWS case, setting up credentials could be a challenge for many. But if barriers to access are reduced both in terms of  developer experience/novice usability and in terms of computer requirements (eg providing something that can be run from an old low spec machine with an easy to install package) that it allows more people to use software distributed by containers even if they aren't Docker developers themselves. (But being able to use third party/off-the-shelf containers easily may encourage then to explore how to create their own containers.)

I have wanted this for years.

Chocolatery for Windows, apt for Ubuntu, yum, dnf, and other installers for WSL, ...
Docker CLI  and Docker-compose for .....
But the Package manager has to be installed before.
Who will install Docker CLI plugins and Config Docker client config file with DNS configs?
Looks like a long page with links to documentation.
Indeed, Docker daemon is not required on the client-side, i.e. Docker Daemon can be and should be skipped by the User desire but Selection of Docker CLI version, Docker CLI configuration Docker CLI plugins installation and Docker context configuration are needed to make Docker CLI working.
The Low-level Docker Client is Docker REST API which needs only CURL.

Thanks for your idea! This is something we might consider in the future but are not currently working on. Apologies for the delayed response.

Hi folks, we're looking in to this one now. If anyone has the time, I'd really like to chat about this ! Please email<EMAIL_ADDRESS>and I'll schedule something in for us.


Tsserver doesn't discover all files on OpenBSD

🔎 Search Terms
"tsserver openbsd", "file<EMAIL_ADDRESS>is not a module.", "typescript file is not a module", "typescript file is not a module openbsd", "typescript TS2306 openbsd", "typescript TS2306 Eglot", "typescript TS2306 lsp", "tsserver Changing to watchFile", "typescript lsp Changing to watchFile", "typescript emacs eglot openbsd", "tsserver syslog Changing to watchFile", "eglot typescript problem", "create react app typescript lsp", "cannot find name 'document'. do you need to change your target library? try changing the 'lib' compiler option to include 'dom'."
🕗 Version & Regression Information
I was unable to test this on prior versions because I don't believe this to be an issue related to the version of typescript but simply an issue linked with the OS. And I found this issue as soon as I started using the typescript-language-server.
⏯ Playground Link
No response
💻 Code
Case study: Create React App
To test a similar setup on both Linux and OpenBSD, I setup a barebone CRA project with typescript template, I just added the files in a git repo (so that emacs sees the whole project), otherwise there is no modification, just running npx create-react-app ts-test --template typescript should get you the exact same setup.
The code per say works and compile on both OSes, but when using the typescript-language-server on OpenBSD, the tsserver sends wrong diagnostics about this snipet.
import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';

const root = ReactDOM.createRoot(
  document.getElementById('root') as HTMLElement
);
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

🙁 Actual behavior
So I've been trying to setup a typescript dev environment on my OpenBSD box with Emacs+Eglot and latest typescript-language-server. (It may also be worth noting I use node v18.17.1)
So the server start and Emacs is able to communicate with it, without any issues, it even manages to send some diagnostics and display them.
Problem
Now the problem is that it gives me diagnostics when it shouldn't, I increased the log verbosity and it seems that the issues might be related to tsserver, it's in those logs that I observed a difference between a fully functional setup on Linux and a broken one on OpenBSD.
On OpenBSD
As an example, I get diagnostics like the following in the index.tsx file of the CRA project:
    1  18 error    e-f-b    typescript [2306]: File<EMAIL_ADDRESS>is not a module.
    2  21 error    e-f-b    typescript [2306]: File<EMAIL_ADDRESS>is not a module.
    4  16 error    e-f-b    typescript [2306]: File '/home/nature/dev/ts-test/src/App.tsx' is not a module.
    5  28 error    e-f-b    typescript [2306]: File '/home/nature/dev/ts-test/src/reportWebVitals.ts' is not a module.
    8   2 error    e-f-b    typescript [2584]: Cannot find name 'document'. Do you need to change your target library? Try changing the 'lib' compiler option to include 'dom'.
    8  37 error    e-f-b    typescript [2304]: Cannot find name 'HTMLElement'.
   11   2 error    e-f-b    typescript [2306]: File<EMAIL_ADDRESS>is not a module.

And the tsserver.log is the following:
tsserver_openbsd.log
What's mostly different is all those sysLog:: /home/nature/dev/ts-test/node_modules/react:: Changing to watchFile which seems to indicate that those files are not being considered.
When scrolling down we also see that Linux sees something like 200+ files and OpenBSD only 60.
🙂 Expected behavior
On Linux
I get no diagnostics and I get the following tsserver.log:
tsserver_linux.log
All is fine there.
Additional information about the issue
An interesting thing to note is that when I run tsc --watch on the project (on OpenBSD) it's able to compile successfully without errors and notice the changes made to any files within the project (even those that don't seem to be picked up by tsserver).
I also opened an issue on the  typescript-language-server repo but I was redirected here as it seemed more of a tsserver/typescript specific issue:
https://github.com/typescript-language-server/typescript-language-server/issues/745
I've been struggling with this setup for 2 days straight now... So any help will be highly appreciated.

Are you able to try this in some way that doesn’t involve typescript-language-server? I’m not very familiar with OpenBSD so I’m not sure what your options are, but since you say you only started seeing this upon using typescript-language-server, we would really want to remove any third-party components from the equation before trying to investigate.

I use tide which uses the tsserver protocol directly instead of wrapping it with the Language Server Protocol. Do you still see the error if you use tide instead?
Also, @sheetalkamat are you aware of any watch issues on OpenBSD? It sounds like it could be a problem with different definitions of files vs folders or something. (Though that could also be a problem with an LSP wrapper so probably worth trying to eliminate that first.)

Very good suggestion, so I just tried to open the same file with tide and I don't get the same diagnostics, but I still get something that probably shouldn't be there, here it is:
 index.tsx     1   1 error    1208   'index.tsx' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module. (tsx-tide)

Then, looking at the tsserver logs again we can see it being full of those sysLog:: /home/nature/dev/ts-test/node_modules/yaml:: Changing to watchFile lines.
tsserver_openbsd_tide.log
And this times it only seems to be able to find 59 files:
Info 946  [12:27:11.247] Project '/home/nature/dev/ts-test/tsconfig.json' (Configured)
Info 946  [12:27:11.247] 	Files (59)

I could also try the same setup again on Linux and see if things are different there, but I feel something janky is going on with tsserver on OpenBSD, my wild guess is that it could be linked to some usage of fs.watch and fs.watchFile.
When I tried to dig a bit inside the tsserver code, I found that the Changing to watchFile appears when there is an error here: https://github.com/microsoft/TypeScript/blob/v4.9.5/src/compiler/sys.ts#L1152
But the only error code that is checked is ENOSPC but if I am to believe some node documentation I read, nodejs uses kqueue(2) on OpenBSD (don't trust me on that statement), and if that is the case, in the man page it is not specified that it ever returns ENOSPC.
I think it could be interesting to print the error code at this Changing to watchFile syslog statement, to understand which error we are talking about.
Forgive me if I am getting ahead of myself, I am very new to typescript, I am trying to give as much element as I've been able to find over the past 3-4 days.

To double-check: does tsc work when you run it from ~/dev/ts-test?

Ok I tried a few things.
First off, I tried to run tsc from ~/dev/ts-test and it runs fine.
Then I turned off isolatedModules in tsconfig, so no more diagnostics when I open the file, but as soon as I purposefully make a syntax error and save the file I have many errors popping, so I proceed to fix the mistake I just made and save the file again and this time the diagnostics are the exact same as with the typescript-language-server:
 index.tsx     1  19 error    2306   File<EMAIL_ADDRESS>is not a module. (tsx-tide)
 index.tsx     2   8 error    1192   Module '"/home/nature/dev/ts-test/node_modules/@types/react-dom/client"' has no default export. (tsx-tide)
 index.tsx     4  17 error    2306   File '/home/nature/dev/ts-test/src/App.tsx' is not a module. (tsx-tide)
 index.tsx     5  29 error    2306   File '/home/nature/dev/ts-test/src/reportWebVitals.ts' is not a module. (tsx-tide)
 index.tsx     8   5 error    2584   Cannot find name 'document'. Do you need to change your target library? Try changing the 'lib' compiler option to include 'dom'. (tsx-tide)
 index.tsx     8  40 error    2304   Cannot find name 'HTMLElement'. (tsx-tide)

Here is the log:
tsserver_openbsd_tide2.log
Do you want me to try the same manipulation from the Linux setup? I am pretty sure it will end up seeing the 200+ files of the project and not have those sysLog:: /home/nature/dev/ts-test/node_modules/yaml:: Changing to watchFile lines.

I just tried and the wrong diagnostics are still present. :(
here is the logs from tsserver:
tsserver_ts_v5.3.0.log

Have you tried a different editor? VSCode should be easy to set up and it would be interesting to know whether you get the same results. You should -- but my memory of setting up tsserver's interaction with emacs was that were lots of failure points, so vscode should eliminate some of them.

No I have not, and VSCode is unfortunately not available on OpenBSD.
If you have any other suggestions to isolate the issue I could give it a shot.

Coming back here, I would still love to get this working, but as I said VSCode is not supporting OpenBSD at all, there is no port available, and building electron apps on OpenBSD seems to be like asking for pain.
So I'd be willing to try any workeable solutions in order to investigate this further.

I think @sheetalkamat is the only expert in this area, so maybe she will have an opinion.
In the meantime, you could try another tsserver-supporting editor, like vim, to see if it has the same difference. But vim is not necessarily any easier to set up than emacs.

@sheetalkamat Let me know if there is anything more I could provide so that this can move forward.

So looking into the logs it seems like we are not able to set native file watching and hence using polling watch. That should not impact initial project creation. To me it seems like we are not able to find some files for some reason.
Can you enable traceResolution in tsconfig and generate the tsserver log on linux and open bsd so we can compare and see where things deviate.
Also what is surprising is that on linux you get some additional lib files that are referenced through node_modules/typescript/lib/lib.esnext.d.ts (or indirectly from its references) while we dont see those in bsd even though that one is present.
So can you please compare the contents of node_modules/typescript/lib/lib.esnext.d.ts on both platforms.
	node_modules/typescript/lib/lib.es5.d.ts
	  Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.es2015.d.ts'
	  Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.es2015.d.ts'
	node_modules/typescript/lib/lib.es2015.d.ts
	  Library referenced via 'es2015' from file 'node_modules/typescript/lib/lib.es2016.d.ts'
	  Library referenced via 'es2015' from file 'node_modules/typescript/lib/lib.es2016.d.ts'
	node_modules/typescript/lib/lib.es2016.d.ts
	  Library referenced via 'es2016' from file 'node_modules/typescript/lib/lib.es2017.d.ts'
	  Library referenced via 'es2016' from file 'node_modules/typescript/lib/lib.es2017.d.ts'
	node_modules/typescript/lib/lib.es2017.d.ts
	  Library referenced via 'es2017' from file 'node_modules/typescript/lib/lib.es2018.d.ts'
	  Library referenced via 'es2017' from file 'node_modules/typescript/lib/lib.es2018.d.ts'
	node_modules/typescript/lib/lib.es2018.d.ts
	  Library referenced via 'es2018' from file 'node_modules/typescript/lib/lib.es2019.d.ts'
	  Library referenced via 'es2018' from file 'node_modules/typescript/lib/lib.es2019.d.ts'
	node_modules/typescript/lib/lib.es2019.d.ts
	  Library referenced via 'es2019' from file 'node_modules/typescript/lib/lib.es2020.d.ts'
	  Library referenced via 'es2019' from file 'node_modules/typescript/lib/lib.es2020.d.ts'
	node_modules/typescript/lib/lib.es2020.d.ts
	  Library referenced via 'es2020' from file<EMAIL_ADDRESS>	  Library referenced via 'es2020' from file 'node_modules/typescript/lib/lib.es2021.d.ts'
	node_modules/typescript/lib/lib.es2021.d.ts
	  Library referenced via 'es2021' from file 'node_modules/typescript/lib/lib.es2022.d.ts'
	node_modules/typescript/lib/lib.es2022.d.ts
	  Library referenced via 'es2022' from file 'node_modules/typescript/lib/lib.esnext.d.ts'

Hi @sheetalkamat sorry for the delay, I was a bit busy last week.
First off, here are all the logs I was able to get when running typescript-language-server --stdio --log-level 4 --tsserver-log-verbosity verbose with eglot on emacs:
tsserver_semantic_openbsd.log
tsserver_syntax_openbsd.log
tsserver_semantic_linux.log
tsserver_syntax_linux.log
Also here is the diff between the two lib.esnext.d.ts files:
--- lib.esnext.openbsd.d.ts     Sat Sep 16 18:09:42 2023
+++ lib.esnext.linux.d.ts       Sat Sep 16 18:10:13 2023
@@ -14,9 +14,9 @@
 ***************************************************************************** */

-/// <reference no-default-lib="true"/>

-/// <reference lib="es2023" />
-/// <reference lib="esnext.intl" />
-/// <reference lib="esnext.decorators" />
-/// <reference lib="esnext.disposable" />
+/// <reference no-default-lib="true"/>
+
+
+/// <reference lib="es2022" />
+/// <reference lib="esnext.intl" />

It's actually quite strange that both files are different since I really followed the exact same procedure of using create-react-app (exact same version of node) on both machines.
Both files for reference (had to add .txt to upload them):
lib.esnext.linux.d.ts.txt
lib.esnext.openbsd.d.ts.txt

The typescript version you are running on both these are different so that would explain changes in lib files:
// From openBSD log
Info 0    [15:52:54.434] Starting TS Server
Info 1    [15:52:54.435] Version: 5.3.0-insiders.20230829

// From Linux log
Info 0    [16:00:44.413] Starting TS Server
Info 1    [16:00:44.418] Version: 4.9.5

Hi @sheetalkamat,
I am sorry, I didn't realize I kept the tsserver version from https://github.com/microsoft/TypeScript/issues/55540#issuecomment-1698086360.
I reset the version and here are the logs with the correct version on OpenBSD:
tsserver_semantic_openbsd.log
tsserver_syntax_openbsd.log
I also checked node_modules/typescript/lib/lib.esnext.d.ts and now there are no difference at all between the file on Linux or OpenBSD.

I don't think this issue should be closed.
It still is not working on OpenBSD and we haven't found any explainations yet, I produced all the required logs and this time with the specific traceResolution option as well as maximum verbosity. Of course with the same version on Linux and OpenBSD, I tried my best to investigate this a month ago and my initial thought was that there is something fishy going on with the file discovery and those sysLog:: /home/nature/dev/ts-test/node_modules/react:: Changing to watchFile messages.
Unfortunately I don't have enough knowledge of tsserver to start making custom builds and debugging it...

Can you please upgrade to nightly typescript and use latest create-react-app and get me logs on linux vs openBSD from just so we can avoid any fixed issue. (with traceResolution enabled.
I would also like you to share the source code with node_modules folder as is so that we can verify that contents are same.
I noticied few discripencies in linux and open bsd logs:
isolatedModules is true on linux but not on openbsd. Not sure i
First place where resolutions goes differently is the absence of following resolution from open bsd:
======== Resolving module './' from<EMAIL_ADDRESS>========
Info n  [dd:mm:yy:mmm] Explicitly specified module resolution kind: 'NodeJs'.
Info n  [dd:mm:yy:mmm] Loading module as file / folder, candidate module location<EMAIL_ADDRESS>target file type 'TypeScript'.
Info n  [dd:mm:yy:mmm] File<EMAIL_ADDRESS>does not exist.
Info n  [dd:mm:yy:mmm] File<EMAIL_ADDRESS>does not exist.
Info n  [dd:mm:yy:mmm] File<EMAIL_ADDRESS>does not exist.
Info n  [dd:mm:yy:mmm] File<EMAIL_ADDRESS>exist - use it as a name resolution result.
Info n  [dd:mm:yy:mmm] ======== Module name './' was successfully resolved to<EMAIL_ADDRESS>========

also for what it's worth, if you're still running into issues with the latest TypeScript (and have followed all of Sheetal's instructions), a more up-to-date version of the inode PR is going to be available here: https://github.com/microsoft/TypeScript/pull/55567#issuecomment-1738006493


Docker footer show the commit instead of tag version in 1.5.0

Gitea version (or commit ref): 1.5
Git version:
Operating system: Docker
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

Description
In Docker in the footer of the page the displayed version is the commit instead of the version of the tag.
I see this description for the version 1.5.0 / 1.5.0-rc2 / 1.5.0-rc1 / 1.5.0-dev.
The version 1.4.3 show the correct version ( 1.4.3 )
...
Screenshots
Version 1.5.0:

Version 1.4.3:

Are you using tag 1.5 or 1.5.0?

I use this docker-compose.yml:
version: "2"

networks:
        gitea:
            external: false
services:
    gitea:
       container_name: gitea
       image: gitea/gitea:1.5.0
       environment:
           - USER_UID=112
           - USER_GID=117
       restart: always
       networks:
           - gitea
       volumes:
           - /home/git/gitea:/data
       ports:
           - "<IP_ADDRESS>:3000:3000"
           - "<IP_ADDRESS>:10022:22"

Hmm, strange. Must be something to do with that standard tag drone feature

It seems the fix doesn't worked. On 1.6.0 the footer says "0da8bc9".

Still an issue with 1.8.0.

Do you get gitea binary from the https://dl.gitea.io ?

@lunny Problem is only in Docker..

As @webjoel said it is a problem with the Docker build.

I think tags: true doesn't actually exist in Drone, and you need to do git fetch --tags by yourself as a separate step to get the tags. See Drone - --tags

You can use DRONE_TAG to get the git tag in some circumstances - https://docs.drone.io/reference/environ/drone-tag/

The problem is that the variable DRONE_TAG and DRONE_BRANCH that are used in the Makefile are not forwarded to the docker context and so the the build inside docker doesn't take them into account.

Fixed by #6836 and its backport #6839

Hmm actually this one might not be fixed - it depends on when we make the tag. If we tag after building then that's the problem...


Question about running gpu

Hello,
I am following the tutorial to preprocess snRNA-seq and snATAC-seq data. The steps below have not finished after 16 hours.
scglue.data.lsi(atac, n_components=100, n_iter=15)
sc.pp.neighbors(atac, use_rep="X_lsi", metric="cosine")
sc.tl.umap(atac)
sc.pl.embedding(atac, basis="X_umap",color=[label_atac], ncols=1,frameon=False,save=f'_{cell}_atac.png', palette="tab20")
There are 66532 cells and 462718 peaks in snATAC-seq. The code seems not be able to use gpu, are running with 8 CPU and use a lot of memory. I wonder if you know the reason why it took so long to run these steps. I have installed pytorch-gpu, but it seems there is no option/parameter to call gpu for scGlue. Could you let me know how to run scGlue with gpu?
Also, I wonder how to set seed for scGlue to reproduce the results.
Thanks a lot!

Thanks for your interest in GLUE! The preprocessing steps cannot utilize GPU, but a 66532 * 462718 matrix should not take more than a couple of minutes. Could you verify that the count matrix is in a sparse format? If it's densely stored it would take more time and memory. You may also run these line by line to see which line exactly is taking the most time.

Thanks a lot for the reply! The count matrix is in a sparse format.


Remove Sources type

I have heard that Sources were an old type needed for Chronograf, but they are no longer used.
If it's code we aren't using and won't use, let's get rid of it.

Sources appear to still exist.

see also: https://github.com/influxdata/influxdb/issues/15571
Looks like this needs to be removed entirely.


Fixing Trash Can and Pillar

Need to fix the models + textures for the trash can and pillar models

still need some work, but they are usable in this state. If there is time, I will go back and edit the pillar. The trash can needs to be a bit slimmer too.


User Management backend - Base - DB Models

fixes #27.
This PR depends on PR #38.
Created two DB models - Token and User, and defined their tables schema.
@DoRTaL94  @RoniRush

@simzacks Although this branch has been merged, I can't see the models in the master 😕

#38 was merged after this one.
Unfortunately, it didn't show that code in the code review, so I couldn't see that it was deleting the models :-(
I didn't notice it when I merged #38, but I did in #39 and #40 and made comments that I can't do the code review because of this.


Remove: Telerik.Fiddler.Everywhere.Insiders version 4.0.0-insiders

Microsoft Reviewers: Open in CodeFlow

URL: https://downloads.getfiddler.com/win/Fiddler Everywhere 4.0.0-insiders.exe
OK
(Automated message - build 912)


add docs for host field in .status

What type of PR is this?
/kind documentation
What does this PR do / why we need it:
Adds documentation about how to utilize the .host field under the Argo CD operand's .status field that was added in PR https://github.com/argoproj-labs/argocd-operator/pull/514

/retest


Bug 1879182: make secure- and normal audit policies match

/assign @sttts
We no longer need to be treating the oauth tokens differently as they bear very little information that could be misused.

/hold
this is the wrong way. Remove the unnecessary policies.

/test unit
that does not seem to be relevant to this PR, interesting for a unit test to fail like that though

/hold cancel
/lgtm
/approve


Use Gem::Specification.load to activate gems in bundler/setup standalone script

Fixes #2720.

Please add a test for this? Thanks!

Thanks for opening this PR and helping make Bundler better. On top of the missing spec Rubocop has also detected a few linting problems, you can run it locally via bin/rubocop  👍

Thanks for the feedback, I'll fix the linting issues and add tests now.

Now with tests!

Urgh, it worked when I tested it locally but I broke a few things when tidying it up for review. Tests should be green now.

diff --git a/spec/install/gems/standalone_spec.rb b/spec/install/gems/standalone_spec.rb
index eb9d6e1c7..1babf7d38 100644
--- a/spec/install/gems/standalone_spec.rb
+++ b/spec/install/gems/standalone_spec.rb
@@ -92,16 +92,19 @@ RSpec.shared_examples "bundle install --standalone" do
     end

     it "loads gems correctly", :rubygems => "2.4" do
-      testrb = String.new <<-RUBY
-        $:.unshift File.expand_path("bundle")
+      testrb = <<-RUBY
+        $:.unshift "#{bundled_app("bundle")}"
         require "bundler/setup"

         require 'very_simple_binary'
         puts (Gem.loaded_specs['very_simple_binary'] || Gem::Specification.new).name
+
+        require 'very_simple_binary_c'
+        puts VerySimpleBinaryInC
       RUBY
       ruby testrb, :no_lib => true

-      expect(out).to eq("very_simple_binary")
+      expect(out).to eq("very_simple_binary\nVerySimpleBinaryInC")
     end
   end

Thanks, that seemed to work

Gem::Specification#activate also doesn't always seem to be present :O
https://travis-ci.org/bundler/bundler/builds/224607732

Hey, so I'm not 100% sure about making this change in general. The point of standalone mode is to set up the load path and allow you to require your gems without even loading RubyGems or Bundler at all. Activating the gems as gems kind of defeats the point of standalone mode... at that point, why not use bundle exec?
Can you tell us more about what you're trying to do, and why you feel like this change is helpful for you?

@indirect sure, let me elaborate (although, I thought that you had already stated that you would accept a pull request similar to this in https://github.com/bundler/bundler/issues/2720#issuecomment-31313879).
So we are currently using Puppet 3 and we install it using Bundler rather than using a system package. The main reason that we do this is because we want to use a bunch of gems in some custom Puppet code that we have written, and it makes our bootstrapping process much simpler if we simply install all of our dependencies using Bundler.
To run Puppet, we use standalone binstubs (i.e. bundle install --standalone --binstubs && ./bin/puppet apply ...). In most cases, we can simply use bundle exec puppet apply instead of using the standalone binstubs, although this is not always the case. For example, we are using the sbadia/gitlab module for installing Gitlab. Since Gitlab itself is a Ruby application, it also uses Bundler:
  exec { 'install gitlab':
    command => "bundle install${gitlab_bundler_jobs_flag} --without development aws test ${gitlab_without_gems} ${gitlab_bundler_flags}",
    cwd     => "${git_home}/gitlab",
    unless  => 'bundle check',
    timeout => 0,
    require => [
      Gitlab::Config::Database['gitlab'],
      Gitlab::Config::Unicorn['gitlab'],
      File["${git_home}/gitlab/config/gitlab.yml"],
      Gitlab::Config::Resque['gitlab'],
    ],
    notify  => Exec['run migrations'],
  }

This part of the Puppet manifests fails when run through bundle exec puppet apply due to the presence of the BUNDLE_* environment variables, which presumably alter the behavior of bundle install when run from /home/git/gitlab.
Our solution here was to use standalone binstubs, but we have run into an issue when trying to upgrade to Puppet 4. Specifically, the standalone binstub for Puppet 4 no longer seems to execute correctly:
/etc/puppet/vendor/bundle/ruby/2.1.0/gems/puppet-4.10.0/lib/puppet.rb:76:in `singleton class': undefined method `version' for nil:NilClass (NoMethodError)
    from /etc/puppet/vendor/bundle/ruby/2.1.0/gems/puppet-4.10.0/lib/puppet.rb:55:in `<module:Puppet>'
    from /etc/puppet/vendor/bundle/ruby/2.1.0/gems/puppet-4.10.0/lib/puppet.rb:49:in `<top (required)>'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /etc/puppet/vendor/bundle/ruby/2.1.0/gems/puppet-4.10.0/lib/puppet/util/command_line.rb:12:in `<top (required)>'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/rbenv/versions/2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /etc/puppet/vendor/bundle/ruby/2.1.0/gems/puppet-4.10.0/bin/puppet:4:in `<top (required)>'
    from /etc/puppet/bin/puppet:14:in `load'
    from /etc/puppet/bin/puppet:14:in `<main>'

From inspection of the Puppet source code, they are simply checking Gem.loaded_specs.

So my understanding is that the difference between bundle install --binstubs and bundle install --standalone --binstubs is that the latter avoids dependencies on both Bundler and RubyGems? I guess that, in my case, really I just want to avoid the dependency on Bundler.

@joshuaspence as I stated in the PR that you linked to:

Standalone mode was never intended to duplicate the regular setup.rb, and in fact exists specifically for times when people don't want to use rubygems or Bundler inside their app, just call "require" and have their load path already set up.

Standalone mode is specifically designed for users who want to use only $LOAD_PATH + require at runtime, without RubyGems or Bundler being loaded or used in any way.
Bundler already contains a way to use bundle exec and still successfully run other Bundled applications: bundle exec ruby -e 'Bundler.with_clean_env { `bundle exec gitlab` }' should do exactly what you want. Please see the docs for with_clean_env: http://bundler.io/v1.3/man/bundle-exec.1.html#Shelling-out

So what did you mean by this?

That said, now that Rubygems ships inside Ruby, it may not be reasonable to expect people to avoid using Rubygems. Let's do the patch that makes it work.

@joshuaspence four years ago, I said that it might make sense to change standalone mode to ensure that the gem method does not raise an error, either by configuring Gem::Specification.dir or by defining the gem method to be a no-op.
I appreciate your willingness to investigate your problem and come up with a solution. Thank you for sending the PR. The particular problem you are describing (nested bundle invocations) already has a solution that does not require making any changes to Bundler, so I recommend that you use that solution because it both already exists and has been present in every version of Bundler for at least the last five years.
At the meta level, your tone is coming across as pretty combative and entitled right now. Expecting that I will merge this PR because of a comment I made four years ago on a feature request that didn't include any code is extremely shitty and demanding. Please tone it down before you start violating the code of conduct. Thanks.

I apologize if my tone came across as combative, that was not intended. I was simply trying to clarify whether there was a different solution that you were referring to in your previous comment or if your previous comment was simply no longer relevant in the current state.
Of course, I don't expect a PR to be merged unless the maintainers feel that the feature is worthwhile, given that they are the ones who would be required to support the code after it has been merged.

Is there a way to use Bundler.with_clean_env directly from the command line? Something like bundle exec --with-clean-env puppet apply.

@joshuaspence unfortunately, that won't get you what you want. You need to run Puppet inside the context of your bundle, and then you need to run Gitlab in the context of its own Bundle. Inside Puppet, you'll need to either execute Ruby code directly (maybe subclassing the resource you're using to install Gitlab?) or you'll need to tell Puppet to execute a Ruby script whose contents are Bundler.with_clean_env { system(*ARGV) }, or something along those lines.
tl;dr, Bundler can't clean the env for you from the command line because the cleaning needs to be invoked from inside your running Ruby process as it shells out (in this case Puppet running a command).

OK, that makes sense. Thanks for your help and feedback. I think that I can come up with a solution on my end to workaround this.

👍


Using this, how to analyze the color configuration under dark mode?

In dark mode, you can set multiple colors, such as color_ test, any light,dark。 With this example, I don't know how to parse car files.
such as Json:
{
"AssetType" : "Color",
"Color components" : [
0.45899999141693115,
1,
1,
1
],
"Colorspace" : "srgb",
"Name" : "color_set",
"NameIdentifier" : 4492,
"Scale" : 1
},
{
"Appearance" : "UIAppearanceDark",
"AssetType" : "Color",
"Color components" : [
1,
1,
0.11299999803304672,
1
],
"Colorspace" : "srgb",
"Name" : "color_set",
"NameIdentifier" : 4492,
"Scale" : 1
}

I am not sure to fully understand the question. You have a .car file and would like to extract the colors for the various themes (light, dark, ...) using CARParser?
I think that in this case you should see  one CUIThemeColorRendition for each color. Something like:
csiHeader:
	 version: 1
	 renditionFlags: bitmapEncoding 0
	 width: 0
	 height: 0
	 scaleFactor: 0
	 pixelFormat: 0x0000
	 colorSpaceID: 1
	 modtime: 0
	 layout: Color
	 name: MyColor
	 tvlLength: 28
	 renditionLength: 48
	 tlv:
		 BlendModeAndOpacity:<PHONE_NUMBER>000000
		 EXIFOrientation: 01000000

 Found Color 1.000000,0.000000,0.000000,0.500000 with colorspace ID 1

See https://blog.timac.org/2018/1018-reverse-engineering-the-car-file-format/ for more info.
In your json, it seems that you have one color with the name color_set and NameIdentifier 4492. One color has no Appearance so it should be the default while the other is for dark mode with the UIAppearanceDark appearance.
Hopefully this helps.


#SBATCH --ntasks value

Hi,
first of all thank you for this magnificent piece of work.
I would like to run tests using spack as build system and slurm as launcher.
This is my settings.py file:
site_configuration = {
    "systems": [
        {
            "name": "cluster",
            "descr": "cluster",
            "hostnames": [".*"],
            "partitions": [
                {
                    "name": "hpc",
                    "scheduler": "slurm",
                    "launcher": "srun",
                    "access": ["--exclusive", "--partition hpc"],
                    "max_jobs": 2,
                    "environs": ["gnu"],
                },
            ],
        },
    ],
    "environments": [
          {
            "name": "gnu",
            "cc": "gcc-9",
            "cxx": "g++-9",
            "ftn": "gfortran-9"
        },
    ],
    "logging": [
        {
            "level": "debug",
            "handlers": [
                {
                    "type": "stream",
                    "name": "stdout",
                    "level": "info",
                    "format": "%(message)s"
                },
                {
                    "type": "file",
                    "level": "debug",
                    "format": "[%(asctime)s] %(levelname)s: %(check_info)s: %(message)s",
                    "append": False
                }
            ],
            "handlers_perflog": [
                {
                    "type": "filelog",
                    "prefix": "%(check_system)s/%(check_partition)s",
                    "level": "info",
                    "format": (
                        "%(check_job_completion_time)s|reframe %(version)s|"
                        "%(check_info)s|jobid=%(check_jobid)s|"
                        "%(check_perf_var)s=%(check_perf_value)s|"
                        "ref=%(check_perf_ref)s "
                        "(l=%(check_perf_lower_thres)s, "
                        "u=%(check_perf_upper_thres)s)|"
                        "%(check_perf_unit)s"
                    ),
                    "append": True
                }
            ]
        }
    ],
}

This is the test that I am trying to run:
import reframe as rfm
import reframe.utility.sanity as sn

@rfm.simple_test
class Fio(rfm.RegressionTest):
    descr = "fio benchmark"
    valid_systems = ["cluster:hpc"]
    valid_prog_environs = ["*"]
    vars_dirs = parameter(["/mnt/resource"])
    vars_rw = parameter(["read", "write"])
    vars_bs_size = parameter([("4K", "128M"), ("4M", "2G")])
    prerun_cmds = ["set -euo pipefail"]
    executable = "fio"
    executable_opts = [
        "--name=fio",
        "--directory=$VARS_DIRS",
        "--rw=$VARS_RW",
        "--blocksize=$VARS_BS",
        "--size=$VARS_BS",
        "--iodepth=64",
        "--numjobs=$VARS_NUM_JOBS",
        "--group_reporting",
        "--direct=1",
        "--time_based",
        "--runtime=10s",
    ]
    postrun_cmds = ["echo FINISHED"]
#    num_tasks = 0
    build_system = "Spack"

    @run_after("init")
    def set_description(self):
        self.descr = f"FIO check ({self.vars_dirs})"

    @run_before("compile")
    def setup_build_system(self):
        self.build_system.specs = ["fio"]
        self.build_system.install_tree = "/shared/home/vasco/spack/opt/spack"

    @run_before("run")
    def set_variables(self):
        self.variables = {
            "VARS_DIRS": str(self.vars_dirs),
            "VARS_RW": str(self.vars_rw),
            "VARS_BS": str(self.vars_bs_size[0]),
            "VARS_SIZE": str(self.vars_bs_size[1]),
            "VARS_NUM_JOBS": "$(nproc)",
        }

    @sanity_function
    def assert_FINISHED(self):
        return sn.assert_found("FINISHED", self.stdout)

    @run_before("performance")
    def set_perf_patterns(self):
        self.perf_patterns = {
            "IOPS": sn.extractsingle("IOPS=(\S+),", self.stdout, 1, int),
            "BW": sn.extractsingle("BW=(\d+.\d+)(\S+)", self.stdout, 1, float),
        }

Some questions:

I have set prerun_cmds = ["set -euo pipefail"] in order for the job to fail fast, is there a way to add this as settings level, ie for all tests?
As it is now it will build on the login node and then run using slurm:

is there a way to split the build and run in 2 separate jobs run by slurm so the build will happen on the same kind of node as the run?
keep the dependency between nodes of the same partition, for example if I run the same test with 4 parameters on 2 partition I expect slurm 10 jobs (2 builds, 8 runs) each 4 runs, on each partition, will depend on the build; so as soon as the build is finished the 4 runs can run in parallel.

If no num_tasks is specified, reframe will automatically add #SBATCH --ntasks=1, instead if num_tasks = 0 if will add #SBATCH --ntasks=5000.
The second case makes sbatch fail:

$ cat rfm_Fio__tmp_read___4K____128M___job.sh
#!/bin/bash
#SBATCH --job-name="rfm_Fio__tmp_read___4K____128M___job"
#SBATCH --ntasks=5000
#SBATCH --output=rfm_Fio__tmp_read___4K____128M___job.out
#SBATCH --error=rfm_Fio__tmp_read___4K____128M___job.err
#SBATCH --exclusive
#SBATCH --partition hpc
export VARS_DIRS=/tmp
export VARS_RW=read
export VARS_BS=4K
export VARS_SIZE=128M
export VARS_NUM_JOBS=$(nproc)
. $SPACK_ROOT/share/spack/setup-env.sh
spack env activate -V -d rfm_spack_env
spack load fio
set -euo pipefail
srun fio --name=fio --directory=$VARS_DIRS --rw=$VARS_RW --blocksize=$VARS_BS --size=$VARS_BS --iodepth=64 --numjobs=$VARS_NUM_JOBS --group_reporting --direct=1 --time_based --runtime=10s
echo FINISHED
$ sbatch rfm_Fio__tmp_read___4K____128M___job.sh
sbatch: error: Batch job submission failed: Requested node configuration is not available

Is there a way to completely avoid the #SBATCH --ntasks=* line?
Thanks

I managed to split the build and run:
import reframe as rfm
import reframe.utility.sanity as sn
from reframe.utility import udeps

@rfm.simple_test
class FioBuildTest(rfm.CompileOnlyRegressionTest):
    descr = "Fio build"
    valid_systems = ["hpc:hpc"]
    valid_prog_environs = ["*"]
    build_system = "Spack"

    @run_before("compile")
    def setup_build_system(self):
        self.build_system.specs = ["fio"]
        self.build_system.install_tree = "~/spack/opt/spack"

    @run_before("sanity")
    def set_sanity_patterns(self):
        self.sanity_patterns = sn.assert_found("Updating", self.stdout)

@rfm.simple_test
class FioRunTest(rfm.RunOnlyRegressionTest):
    descr = "Fio run"
    valid_systems = ["hpc:hpc"]
    valid_prog_environs = ["*"]
    vars_dirs = parameter(["/tmp"])
    vars_rw = parameter(["read", "write"])
    vars_bs_size = parameter([("4K", "128M"), ("4M", "2G")])
    prerun_cmds = ["set -euo pipefail"]
    executable = "fio"
    executable_opts = [
        "--name=fio",
        "--directory=$VARS_DIRS",
        "--rw=$VARS_RW",
        "--blocksize=$VARS_BS",
        "--size=$VARS_BS",
        "--iodepth=64",
        "--numjobs=$VARS_NUM_JOBS",
        "--group_reporting",
        "--direct=1",
        "--time_based",
        "--runtime=10s",
    ]
    postrun_cmds = ["echo FINISHED"]

    @run_after("init")
    def set_description(self):
        self.descr = f"FIO check ({self.vars_dirs})"

    @run_after("init")
    def inject_dependencies(self):
        self.depends_on("FioBuildTest", udeps.fully)

    @run_before("run")
    def set_variables(self):
        self.variables = {
            "VARS_DIRS": str(self.vars_dirs),
            "VARS_RW": str(self.vars_rw),
            "VARS_BS": str(self.vars_bs_size[0]),
            "VARS_SIZE": str(self.vars_bs_size[1]),
            "VARS_NUM_JOBS": "$(nproc)",
        }

    @sanity_function
    def assert_FINISHED(self):
        return sn.assert_found("FINISHED", self.stdout)

    @run_before("performance")
    def set_perf_patterns(self):
        self.perf_patterns = {
            "IOPS": sn.extractsingle("IOPS=(\S+),", self.stdout, 1, int),
            "BW": sn.extractsingle("BW=(\d+.\d+)(\S+)", self.stdout, 1, float),
        }

But the build step is always run on the login node even if I specified valid_systems = ["hpc:hpc"]

Hi @yellowhat!

But the build step is always run on the login node even if I specified valid_systems = ["hpc:hpc"]

By default the compilation is always local. Could you try setting build_locally=False and see if that fixes your problem?
https://reframe-hpc.readthedocs.io/en/stable/regression_test_api.html#reframe.core.pipeline.RegressionTest.build_locally

@ekouts  thanks the suggestion:
@rfm.simple_test
class FioBuildTest(rfm.CompileOnlyRegressionTest):
    descr = "Fio build"
    valid_systems = ["hpc:hpc"]
    valid_prog_environs = ["*"]
    build_system = "Spack"
    build_locally = False

    @run_before("compile")
    def setup_build_system(self):
        self.build_system.specs = ["fio"]
        self.build_system.install_tree = "~/spack/opt/spack"

    @run_before("sanity")
    def set_sanity_patterns(self):
        self.sanity_patterns = sn.assert_found("Updating", self.stdout)

is building using slurm.
May I ask about --ntasks=5000 above?
Thanks

Also about questions 1 and 2:

I have set prerun_cmds = ["set -euo pipefail"] in order for the job to fail fast, is there a way to add this as settings level, ie for all tests?

There might be a better way, but setting prepare_cmds might be good enough for you? https://reframe-hpc.readthedocs.io/en/stable/config_reference.html#systems-.partitions-.prepare_cmds

As it is now it will build on the login node and then run using slurm... keep the dependency between nodes of the same partition, for example if I run the same test with 4 parameters on 2 partition I expect slurm 10 jobs (2 builds, 8 runs) each 4 runs, on each partition, will depend on the build; so as soon as the build is finished the 4 runs can run in parallel.

If you want to avoid rebuilding for different parameters you might want to use dependencies and split the test in RunOnlyRegressionTest and CompileOnlyRegressionTest. Have a look at this example https://reframe-hpc.readthedocs.io/en/stable/tutorial_deps.html#tutorial-3-using-dependencies-in-reframe-tests
Finally about the --ntasks question, I am not sure but I will have a look and come back to you.

@yellowhat
If you set the num_tasks to 0, then ReFrame will consider this as a flexible test https://reframe-hpc.readthedocs.io/en/stable/manpage.html?highlight=flexible#flexible-node-allocation and will try allocating all the idle nodes.

@teojgo and @ekouts thanks for your answers.
The "idle" policy is a bit problematic, in this case I am trying to allocate one entire node and each partition has a different number of cores. Is there a ways to simply instruct reFrame to not pass the "#SBATCH --ntasks=*" option?
Thanks

Or better overwrite it with number of nodes to be allocated.

@yellowhat so you want to allocate multiple nodes for the build? or a single node with multiple cores?

I am interested in allocating entire nodes:

for building: it is fine 1 node;
for running: depending on the application and the partition a different number of nodes.

Thanks

Setting num_tasks = False result in #SBATCH --ntasks=4999.

@yellowhat yes, it will try to consult slurm to decide how to run. So you have to set the num_tasks to the number of nodes you want to allocate (if each node is going to have one task).

No way to disable num_tasks?

It is not possible to disable it as far as I can see. How do you want your sbatch script to look like. You don't want to emit num_tasks at all?

Ideally:
#SBATCH --job-name=<whatever>
#SBATCH --partition=<partition_name>
#SBATCH --nodes=<num_nodes>
#SBATCH --output=<whatever>.out
#SBATCH --error=<whatever>.err

May I ask which part of the code add the #SBATCH --ntasks=*?
Thanks

This is the line that does what you are asking: https://github.com/eth-cscs/reframe/blob/a88e9334e44557bfe7810da2be1d3c2db46cd046/reframe/core/schedulers/slurm.py#L144
In my opinion, it's better to control everything via the num_tasks, nodes and num_tasks_per_node

Thanks for the link. I will have a think about it.

Thanks for the addition.

The problem with num_tasks is that if slurm has been configured with cgroup enabled, it will limit the job to that.
For example if num_tasks = 2 on a 4 core node and run an mpirun -np 4 <exec> you will have 4 process running on 2 cores.
Does this make sense?
Is the field num_tasks_per_node fullfilled by reFrame based on the partition if not explicitly specified?
Or better can I specify the number of cores per node on each partition definition in the settings.py so I can simply say num_tasks = 1 * num_cores_per_node?

Another question: if I want to compile on multiple partitions:
@rfm.simple_test
class FioBuildTest(rfm.CompileOnlyRegressionTest):
    descr = "Fio build"
    valid_systems = ["hpc:hpc", "hpc:hpc1"]
    valid_prog_environs = ["*"]
    build_system = "Spack"
    build_locally = False

    @run_before("compile")
    def setup_build_system(self):
        self.build_system.specs = ["fio"]

    @run_before("sanity")
    def set_sanity_patterns(self):
        self.sanity_patterns = sn.assert_found("Updating", self.stdout)

@rfm.simple_test
class FioRunTest(rfm.RunOnlyRegressionTest):
    descr = "Fio run"
    valid_systems = ["hpc:hpc", "hpc:hpc1"]
    valid_prog_environs = ["*"]
    vars_nnodes = parameter([1])
    vars_dirs = parameter(["/tmp"])
    vars_rw = parameter(["read", "write"])
    vars_bs_size = parameter([("4K", "128M"), ("4M", "2G")])
    prerun_cmds = ["spack load fio arch=$(spack arch)"]
    executable = "fio"

    @run_after("init")
    def inject_dependencies(self):
        self.depends_on("FioBuildTest", udeps.fully)
...

The dependency tree:
Full test DAG:
  ('FioBuildTest', 'hpc:hpc1', 'gcc') -> []
  ('FioBuildTest', 'hpc:hpc', 'gcc') -> []
  ('FioRunTest_1__tmp_read___4K____128M__', 'hpc:hpc1', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_read___4K____128M__', 'hpc:hpc', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_read___4M____2G__', 'hpc:hpc1', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_read___4M____2G__', 'hpc:hpc', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_write___4K____128M__', 'hpc:hpc1', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_write___4K____128M__', 'hpc:hpc', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_write___4M____2G__', 'hpc:hpc1', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]
  ('FioRunTest_1__tmp_write___4M____2G__', 'hpc:hpc', 'gcc') -> [('FioBuildTest', 'hpc:hpc1', 'gcc'), ('FioBuildTest', 'hpc:hpc', 'gcc')]

The build is serial: hpc1 and then hpc and then the runs. Is there a wau to have parallel build?
Thanks


Change train-search in wandb to use Sweeps

This PR adds Weights & Biases Sweeps as a replacement for the current train-search command implementation in integrations/wandb.
I've removed the existing scripts which generate multiple spaCy configs and run each pipeline. They are replaced with two scripts which can either run Sweeps using a sweep YAML config file or via the wandb python API. There's also a small bit of spaCy + thinc code which merges the spaCy + wandb sweeps configs, I'm sure there's other ways to do this, open to suggestions here.
I've leaned towards using one ground truth spaCy config for the entire pipeline, with only the hyperparameters in question being in the sweeps config.

I'm sure there's other ways to do this, open to suggestions here.

Not sure if this is a better approach, but spacy train also supports reading the config.cfg from standard input if you set it to -. So you can do something like:
python generate_config.py | spacy train -

All the generate_config.py script needs to do is output the generated config's string representation, e.g. print(config.to_str()). You could even take this one step further and make the script a CLI with typer so it could take different arguments/options/flags.

Thanks for the suggestion. That's a really nice feature, I think using spacy train directly is great and most users probably want that. My only concern is that piping via stdout into spacy train - feels slightly magical and less typical than just using the train function. I think a compromise would be to make this possible via a command line argument but default to use the train function. Would this suffice or what do you think?


encoding/json: misleading error for end-of-input in an escape sequence

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

$ go version
go version go1.20.1 linux/amd64

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

What did you do?

I fed the JSON parser a truncated JSON document that has a backslash as the final rune.
package main

import (
	"encoding/json"
	"fmt"
)

func main() {
	var obj any
	err := json.Unmarshal([]byte(`"\`), &obj)
	fmt.Println(err)
}

https://go.dev/play/p/KxvQ6lpnT7I
What did you expect to see?
I expected the error to be unexpected end of JSON input
What did you see instead?
I saw the error invalid character ' ' in string escape code, which is a nonsense error as there is no   character in the input at all!
json.Compact and json.Indent have the same issue, while json.Decoder.Decode correctly returns io.ErrUnexpectedEOF.

@dsnet @bradfitz @mvdan per owners.

I think the root case of the issue is the function below:
func (s *scanner) eof() int {
	if s.err != nil {
		return scanError
	}
	if s.endTop {
		return scanEnd
	}
	s.step(s, ' ')
	if s.endTop {
		return scanEnd
	}
	if s.err == nil {
		s.err = &SyntaxError{"unexpected end of JSON input", s.bytes}
	}
	return scanError
}

I do update s.err == nil to be s.err != nil but causes some test cases to fail

A similar error in the past: https://github.com/golang/go/issues/56332
There are a handful of these "confusing error message" bug reports on encoding/json. My intuition is that we shouldn't try to fix each one of them individually. cc @dsnet

I have an experimental CL in progress that completely switches the "encoding/json" parser to a new implementation, which will fix most (if not all) of these weird error cases.

I guess I should mention that I'm finding these issues by fuzzing my own JSON parser against encoding/json. My implementation is GPL, but I'm 100% willing to re-license it for incorporation in to the stdlib if there's anything that you'd like to steal.


wasm: program allocs too much memory

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

$ go version
go version go1.12.13 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/5kbpers/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/5kbpers/go-linux-amd64-bootstrap"
GOPROXY=""
GORACE=""
GOROOT="/home/5kbpers/go-linux-amd64-bootstrap"
GOTMPDIR=""
GOTOOLDIR="/home/5kbpers/go-linux-amd64-bootstrap/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build234335217=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Hello! I compiled the following program to WASM:
package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("Hello, WebAssembly!")
        time.Sleep(time.Millisecond * 500)
    }
}

After opening it with my browser (Chrome 78.0.3904.70), take a memory snapshot, that shows it allocs about 1GB memory:

I found a related issue https://github.com/golang/go/issues/27462, adjust the preallocated memory to 64MB:
// writeMemorySec writes the section that declares linear memories. Currently one linear memory is being used.
func writeMemorySec(ctxt *ld.Link) {
	sizeOffset := writeSecHeader(ctxt, sectionMemory)

	// Linear memory always starts at address zero.
	// The unit of the sizes is "WebAssembly page size", which is 64Ki.
	// The minimum is currently set to 1GB, which is a lot.
	// More memory can be requested with the grow_memory instruction,
	// but this operation currently is rather slow, so we avoid it for now.
	// TODO(neelance): Use lower initial memory size.
	writeUleb128(ctxt.Out, 1)       // number of memories
	ctxt.Out.WriteByte(0x00)        // no maximum memory size
	writeUleb128(ctxt.Out, 1024) // minimum (initial) memory size

	writeSecSize(ctxt, sizeOffset)
}

But the allocated memory is still very high (about 780MB):

What did you expect to see?
The allocated memory should approximately be 64MB after adjusting the preallocated memory.
What did you see instead?
The allocated memory is too much higher than expected.

What version of Go are you using (go version)?
go version go1.12.13 linux/amd64

#27462 was fixed for Go1.13 so please try with that version.

Isn’t this likely a duplicate of #35111 (which is fixed on tip)?

How so? #35111 is a memory leak (the memory starts low and keeps increasing), on this one OP immediately sees that the wasm program takes 1GB of RAM.
The "wasm programs start with 1GB of RAM taken" issue is #27462 , which I linked above.

@ALTree Go1.13 works to this, thank you!
BTW, I'm curious about why it still allocates 780MB memory after the initial size was adjusted to 64MB.

@5kbpers

Go1.13 works to this, thank you!

Nice, I'll close this issue then.

BTW, I'm curious about why it still allocates 780MB memory after the initial size was adjusted to 64MB.

You mean the patch you posted above that you manually applied? I'm not sure, it's likely that it just wasn't enough to fix the issue or possibly you did not build the patched toolchain correctly so it didn't pick up your change.


feat(starknet_api, protobuf): add l2_gas_price to block header

This change is

#641  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @TzahiTaub and the rest of your teammates on  Graphite

crates/starknet_client/src/reader/objects/block.rs line 62 at r2 (raw file):
Previously, DvirYo-starkware wrote…
If I understand this PR correctly, this field will be retroactively present in old blocks. If this is the case, you can remove the #[serde(default)].

No, because we want the client to support 0.13.2 and 0.13.3 during the time period when 0.13.3 is in integration but not in mainnet


This is wrong: The private key on you local system is used by an SSH client

The more accurate way to say it would be:
The private key stored on your local system is leveraged by the SSH daemon on the VM to authenticate your identity when you connect to your Linux VM.

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

ID: 33cf041a-95dd-6332-52bf-6a71d3767bb8
Version Independent ID: 96efc8cf-53e0-8a1c-fcf2-122f1b50b152
Content: Use SSH keys with Windows for Linux VMs
Content Source: articles/virtual-machines/linux/ssh-from-windows.md
Service: virtual-machines-linux
GitHub Login: @dlepow
Microsoft Alias: danlep

@DMoonesinghe
I have assigned the issue to the content author to investigate further and update the document as appropriate.
@dlepow Please take care of this issue.

@DMoonesinghe - Thanks again for the feedback. Your suggestion is more technically precise than what is currently written. However, I think it's important also to mention the SSH client, since that's a major focus of the article. I will aim to combine both in a way that addresses the Windows customer audience.
#in-progress

PR merged with text clarification, and will publish later today or tomorrow AM. Closing this issue.
#please-close

Closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Store HGNC IDs for genes

To enable linking to ClinGen.

Mapping available from https://www.genenames.org/download/custom/


Picutre still show old naming convention ATP P1 and P2

[Enter feedback here]
Please update the picture reference design with MDO P1 and MDO P2

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

ID: 3369738b-f096-6c2e-22d4-ee79057997c7
Version Independent ID: d3fce773-a1e8-193a-b4fa-7f71b9ac3ea4
Content: Office 365 Security, Microsoft Defender for Office 365, EOP, MSDO - Office 365
Content Source: microsoft-365/security/office-365-security/overview.md
Product: m365-security
Technology: mdo
GitHub Login: @MSFTTracyP
Microsoft Alias: tracyp

@CristianDEA THank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/5604
Once the author approves the changes will reflect in the document.
Thanks
Sri

@MSFTTracyP  PR merge request pending. Thanks


Deleting a feature image becomes "" instead of null and breaks filter query

Hello,
I was trying to get all posts that have set a featured image.
{{#get "posts" limit="5" filter="id:-{{id}}+feature_image:-null"}}
First ... I imported all the content from another blog. And the rule feature_image:-null was ignored.
I created a new post without the featured image and the filter works. It doesn't get the post. Then I set a featured image, saved the post, removed the featured image and saved again the post. Now the rule feature_image:-null gets ignored and the query selects the new post, even if it doesn't have an image.
So something is set in db instead of null after the featured image gets removed.
I exported the json and checked the feature_image value.
When I created the post the value was "feature_image": null and it was good, but after I set the image and removed it, it became "feature_image": "".
This breaks the filter query.
P.S. In this url: https://api.ghost.org/docs/filter ... it says filter="featured:true,image:-null" and should, probably, be filter="featured:true,feature_image:-null" and images:-null shoud be feature_image:-null

Ghost Version: 1.10.0

Hey @NistorCristian
Using {{#get "posts" filter="feature_image:-null"}} definitely works. Everything else depends on your code e.g. i can't guess if this id:-{{id}} is used in the correct context with a correct value.

P.S. In this url: https://api.ghost.org/docs/filter ... it says filter="featured:true,image:-null" and should, probably, be filter="featured:true,feature_image:-null" and images:-null shoud be feature_image:-null

Thanks will update our docs.
Closing, because this is not a bug. Please wait for help in slack, thanks!

As I said {{#get "posts" filter="feature_image:-null"}} works.
But it doesn't work after I do this:
Add featured image. Save post.
Remove image. Save post.
The problem is not really with the filter tag. Is more with the fact that when I delete the featured image the value in json becomes "" instead of null.

Okay i see what you mean. This affects all images, because the admin client sends an empty string instead of null.
@kevinansfield Could we change this behaviour in the admin client?
@NistorCristian I don't have a workaround for you, because our parser does not allow checking for empty strings.

@kirrg001 No problem, I'm on local. Just testing 😄

@kirrg001 the client behaviour can be changed but it's probably something that needs to be enforced at the server level too along with a migration to ensure consistency between old and new posts


is there way to control tooltip text?

for example I need to format the value in tooltip which in my case is 1.333333333333333 which is not informative at all but take a lot of space..

Yes there is a way. You need to add option parameter called unitTransform, which is a function applied to the value before shown in the tooltip.
It works with barchart.
Check the GraphTests.html file which has the example. Basically if the parent viewModel has a function "valueToLabel" the following will work:


Update banner on argoproj.io

Please update banner saying
"Argo 2.0 coming soon as Custom Resource Definition to be up and running in less than a min and able to create workflows as custom kubernetes resources" Please reach out to Google group (https://groups.google.com/forum/#!forum/argoproj) for early access...

Implement the banner as per the attached design.


Edit Shortcut shortcut not working (cmd + .)

Describe the bug
A clear and concise description of what the bug is.
Shortcut for opening Edit Shortcut Keys noops
To Reproduce
Steps to reproduce the behavior.

Click Edit Shortcut Keys or attempt to use 'cmd + .'
Expected behavior
A clear and concise description of what you expected to happen.
json shortcut file should be open
Screenshots
If applicable, add screenshots to help explain your problem.
Technical Info (please complete the following information)

OS:

Tusk Version:0.11

Additional context
Add any other context about the problem here.

Try setting a text editor as the default app for opening ~/.tusk.json or JSON files in general. Please feel free to reach out again if the issue persist.


Add async-to-promises Babel plugin

This plugin claims to enable async/await without generators.
https://github.com/marten-de-vries/kneden

We should look out for these cases https://github.com/marten-de-vries/kneden/issues/13

The change looks good, but I don't think we're ready to put this transform in the preset until we've tested it out a bit and it handles a few more cases.

Cool cool cool, makes sense.

Just by curiosity, what do you think of fast-async? Would this be a good candidate too?

To clarify - for us to be able to use async/await, we need a transform (any transform) that either a) transforms 100% of the spec, or b) can be combined with a linter rule that fully forbids the parts of the spec that it can't transpile.

I don't plan on working on this any time soon. Some brave soul should feel free to resurrect.


add support for parsing ASSERT_BEFORE_

This adds support for parsing 4 new condition codes, ASSERT_BEFORE_{HEIGHT|SECONDS}_{ABSOLUTE|RELATIVE}.
These conditions are similar to the existing height/seconds asserts but instead of asserting the block height is above the limit, it asserts it's below the limit. This affects how multiple instances of the same condition are aggregated in the parsed state. These conditions preserve the lowest value, since that's the most restrictive.
There's a new flag, ENABLE_ASSERT_BEFORE which needs to be passed in to the conditions parser to enable support for the new conditions. This flag is necessary in order to soft-fork in the conditions while preserving existing behavior until it activates. e.g. if you include one of these conditions but with an invalid parameter, parsing will fail. The behavior prior to supporting these conditions, any unknown conditions would be ignored without parsing the argument.

The aspect of this patch I'm not entirely sure about is the flag to enable support (ENABLE_ASSERT_BEFORE). It adds a fair amount of complexity, but mostly test cases (not every combination of flags are tested today anyway).
The reason this flag is necessary is quite subtle, and it's about avoiding accidentally activating the soft-fork early. Even though this is just parsing, and we (in theory) could decide whether to honor the semantics of the conditions or not at a later point (to activate the soft-fork), the problem is that just parsing, and possibly failing to parse, is a change in behavior.
An alternative approach would be to have parse failures be ignored and the whole condition is just treated as if it's not there. However, after the soft-fork has activated, presumably we would want the parsing to be strict, so we would still need some flag to indicate wither we are before or after activation.

Not relevant to this patch, but I worry that a not care hack to the mempool might lock up the chain if all farmers suffer from the same bug of not ejecting no-longer-valid spends from the mempool before trying to make a block.


[Build][Windows 11] Failing to complete build with publish step based on current docs

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Following exactly docs on Windows build requirements and commands I do get the following error:
Command after bootstrapping and importing build.psm1 module:
Start-PSBuild -Clean -Detailed -PSModuleRestore -UseNuGetOrg
VERBOSE: Build experimental feature list by running 'Get-ExperimentalFeature' &: The term 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. ConvertFrom-Json: Cannot bind argument to parameter 'InputObject' because it is null. Get-Content: Cannot find path 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh.deps.json' because it does not exist. PropertyNotFoundException: The property 'targets' cannot be found on this object. Verify that the property exists. PropertyNotFoundException: The property 'targets' cannot be found on this object. Verify that the property exists.
Expected behavior
What I would expect is the following output and freshly build pwsh bundle in output directory i.e.:

`
Build succeeded in 6.6s
PowerShell output: c:/powershell/artifacts/release/pwsh.exe
Restore PowerShell modules to c:\powershell\artifacts\release
Name='PowerShellGet', Version='2.2.5', Destination='c:\powershell\artifacts\release\Modules'
Name='PackageManagement', Version='<IP_ADDRESS>', Destination='c:\powershell\artifacts\release\Modules'
Name='Microsoft.PowerShell.PSResourceGet', Version='1.0.5', Destination='c:\powershell\artifacts\release\Modules'
Name='Microsoft.PowerShell.Archive', Version='1.2.5', Destination='c:\powershell\artifacts\release\Modules'
Name='PSReadLine', Version='2.3.5', Destination='c:\powershell\artifacts\release\Modules'
Name='ThreadJob', Version='2.0.3', Destination='c:\powershell\artifacts\release\Modules'
VERBOSE: runtime pattern check: win7-x64 -match ^win.*-X64
VERBOSE: Generating experimental feature list
VERBOSE: Build experimental feature list by running 'Get-ExperimentalFeature'
VERBOSE: Removing microsoft.diasymreader.native.amd64.dll from pwsh.deps.json
VERBOSE: Performing the operation "Remove File" on target "C:\powershell\artifacts\release\microsoft.diasymreader.native.amd64.dll".
`

Actual behavior
Please find complete cmd log output for failing build:

`
Start-PSBuild -Clean -Detailed -PSModuleRestore -UseNuGetOrg

Cleaning your working directory. You can also do it with 'git clean -fdX --exclude .vs/PowerShell/v16/Server/sqlite3'
Removing .vs/
Removing src/Microsoft.Management.Infrastructure.CimCmdlets/bin/
Removing src/Microsoft.Management.Infrastructure.CimCmdlets/gen/
Removing src/Microsoft.Management.Infrastructure.CimCmdlets/obj/
Removing src/Microsoft.Management.UI.Internal/bin/
Removing src/Microsoft.Management.UI.Internal/gen/
Removing src/Microsoft.Management.UI.Internal/obj/
Removing src/Microsoft.PowerShell.Commands.Diagnostics/bin/
Removing src/Microsoft.PowerShell.Commands.Diagnostics/gen/
Removing src/Microsoft.PowerShell.Commands.Diagnostics/obj/
Removing src/Microsoft.PowerShell.Commands.Management/bin/
Removing src/Microsoft.PowerShell.Commands.Management/gen/
Removing src/Microsoft.PowerShell.Commands.Management/obj/
Removing src/Microsoft.PowerShell.Commands.Utility/bin/
Removing src/Microsoft.PowerShell.Commands.Utility/gen/
Removing src/Microsoft.PowerShell.Commands.Utility/obj/
Removing src/Microsoft.PowerShell.ConsoleHost/bin/
Removing src/Microsoft.PowerShell.ConsoleHost/gen/
Removing src/Microsoft.PowerShell.ConsoleHost/obj/
Removing src/Microsoft.PowerShell.CoreCLR.Eventing/bin/
Removing src/Microsoft.PowerShell.CoreCLR.Eventing/gen/
Removing src/Microsoft.PowerShell.CoreCLR.Eventing/obj/
Removing src/Microsoft.PowerShell.LocalAccounts/gen/
Removing src/Microsoft.PowerShell.SDK/bin/
Removing src/Microsoft.PowerShell.SDK/obj/
Removing src/Microsoft.PowerShell.Security/bin/
Removing src/Microsoft.PowerShell.Security/gen/
Removing src/Microsoft.PowerShell.Security/obj/
Removing src/Microsoft.WSMan.Management/bin/
Removing src/Microsoft.WSMan.Management/gen/
Removing src/Microsoft.WSMan.Management/obj/
Removing src/Microsoft.WSMan.Runtime/bin/
Removing src/Microsoft.WSMan.Runtime/obj/
Removing src/Modules/obj/
Removing src/ResGen/bin/
Removing src/ResGen/obj/
Removing src/System.Management.Automation/CoreCLR/CorePsTypeCatalog.cs
Removing src/System.Management.Automation/SourceGenerators/PSVersionInfoGenerator/bin/
Removing src/System.Management.Automation/SourceGenerators/PSVersionInfoGenerator/obj/
Removing src/System.Management.Automation/bin/
Removing src/System.Management.Automation/gen/
Removing src/System.Management.Automation/obj/
Removing src/TypeCatalogGen/bin/
Removing src/TypeCatalogGen/obj/
Removing src/TypeCatalogGen/powershell_win7-x64.inc
Removing src/powershell-unix/bin/
Removing src/powershell-unix/obj/
Removing src/powershell-win-core/bin/
Removing src/powershell-win-core/obj/
Removing test/xUnit/bin/
Removing test/xUnit/obj/
Removing tools/wix/obj/
VERBOSE: In Find-DotNet
VERBOSE: Executing:  dotnet --list-sdks
VERBOSE: Find-DotNet: dotnetCLIInstalledVersion = 9.0.100-preview.3.24204.13; chosenDotNetVersion = 9.0.100-preview.3.24204.13
VERBOSE: Using configuration 'Debug'
VERBOSE: Using framework 'net9.0'
VERBOSE: Using runtime 'win7-x64'
VERBOSE: Top project directory is C:\powershell\src\powershell-win-core
Run dotnet restore C:\powershell\src\powershell-win-core --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet /property:EnableWindowsTargeting=True /property:UseRidGraph=True
Restore complete (1.4s)

Build succeeded in 1.7s
Done restoring C:\powershell\src\powershell-win-core
Run dotnet restore C:\powershell/src/TypeCatalogGen --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet /property:EnableWindowsTargeting=True /property:UseRidGraph=True
Restore complete (0.3s)

Build succeeded in 0.6s
Done restoring C:\powershell/src/TypeCatalogGen
Run dotnet restore C:\powershell/src/ResGen --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet /property:EnableWindowsTargeting=True /property:UseRidGraph=True
Restore complete (0.3s)

Build succeeded in 0.5s
Done restoring C:\powershell/src/ResGen
Run dotnet restore C:\powershell/src/Modules --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet /property:EnableWindowsTargeting=True /property:UseRidGraph=True
Restore complete (0.5s)

Build succeeded in 0.7s
Done restoring C:\powershell/src/Modules
Run dotnet restore C:\powershell/tools/wix --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop --verbosity quiet /property:EnableWindowsTargeting=True /property:UseRidGraph=True
Restore complete (1.1s)

Build succeeded in 1.3s
Done restoring C:\powershell/tools/wix
Run ResGen (generating C# bindings for resx files)
Run TypeGen (generating CorePsTypeCatalog.cs)

Build succeeded in 0.6s
Restore complete (0.3s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  TypeCatalogGen succeeded (0.4s) → bin\x64\Debug\net9.0\TypeCatalogGen.dll

Build succeeded in 0.9s
VERBOSE: Building without shim
Run dotnet publish /property:GenerateFullPaths=true /property:ErrorOnDuplicatePublishOutputFiles=false --self-contained /property:UseRidGraph=true /property:IsWindows=true --configuration Debug --framework net9.0 --verbosity d --runtime win7-x64 /property:SDKToUse=Microsoft.NET.Sdk.WindowsDesktop from C:\powershell\src\powershell-win-core
Restore complete (1.2s)

Build succeeded in 1.4s
  Microsoft.WSMan.Runtime succeeded (0.4s) → C:\powershell\src\Microsoft.WSMan.Runtime\bin\x64\Debug\net9.0\Microsoft.WSMan.Runtime.dll
  Microsoft.PowerShell.CoreCLR.Eventing succeeded (0.5s) → C:\powershell\src\Microsoft.PowerShell.CoreCLR.Eventing\bin\x64\Debug\net9.0\Microsoft.PowerShell.CoreCLR.Eventing.dll
  PSVersionInfoGenerator succeeded (0.2s) → C:\powershell\src\System.Management.Automation\SourceGenerators\PSVersionInfoGenerator\bin\x64\Debug\netstandard2.0\SMA.Generator.dll
  System.Management.Automation succeeded (8.0s) → C:\powershell\src\System.Management.Automation\bin\x64\Debug\net9.0\System.Management.Automation.dll
  Microsoft.PowerShell.Security succeeded (1.7s) → C:\powershell\src\Microsoft.PowerShell.Security\bin\x64\Debug\net9.0\Microsoft.PowerShell.Security.dll
  Microsoft.WSMan.Management succeeded (1.9s) → C:\powershell\src\Microsoft.WSMan.Management\bin\x64\Debug\net9.0\Microsoft.WSMan.Management.dll
  Microsoft.PowerShell.Commands.Diagnostics succeeded (2.0s) → C:\powershell\src\Microsoft.PowerShell.Commands.Diagnostics\bin\x64\Debug\net9.0\Microsoft.PowerShell.Commands.Diagnostics.dll
  Microsoft.Management.Infrastructure.CimCmdlets succeeded (1.9s) → C:\powershell\src\Microsoft.Management.Infrastructure.CimCmdlets\bin\x64\Debug\net9.0\Microsoft.Management.Infrastructure.CimCmdlets.dll
  Microsoft.PowerShell.ConsoleHost succeeded (2.0s) → C:\powershell\src\Microsoft.PowerShell.ConsoleHost\bin\x64\Debug\net9.0\Microsoft.PowerShell.ConsoleHost.dll
  Microsoft.PowerShell.Commands.Utility succeeded (2.1s) → C:\powershell\src\Microsoft.PowerShell.Commands.Utility\bin\x64\Debug\net9.0\Microsoft.PowerShell.Commands.Utility.dll
  Microsoft.PowerShell.Commands.Management succeeded (1.2s) → C:\powershell\src\Microsoft.PowerShell.Commands.Management\bin\x64\Debug\net9.0\Microsoft.PowerShell.Commands.Management.dll
  Microsoft.PowerShell.SDK succeeded (0.8s) → C:\powershell\src\Microsoft.PowerShell.SDK\bin\x64\Debug\net9.0\Microsoft.PowerShell.SDK.dll
  Microsoft.PowerShell.GraphicalHost succeeded (2.2s) → C:\powershell\src\Microsoft.Management.UI.Internal\bin\x64\Debug\net9.0\Microsoft.PowerShell.GraphicalHost.dll
  powershell-win-core net9.0 succeeded (2.5s) → bin\x64\Debug\net9.0\win7-x64\publish\

Build succeeded in 14.8s
PowerShell output: C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh.exe
Restore PowerShell modules to C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish
Name='PowerShellGet', Version='2.2.5', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
Name='PackageManagement', Version='<IP_ADDRESS>', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
Name='Microsoft.PowerShell.PSResourceGet', Version='1.0.5', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
Name='Microsoft.PowerShell.Archive', Version='1.2.5', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
Name='PSReadLine', Version='2.3.5', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
Name='ThreadJob', Version='2.0.3', Destination='C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\Modules'
VERBOSE: runtime pattern check: win7-x64 -match ^win.*-X64
VERBOSE: Generating experimental feature list
VERBOSE: Build experimental feature list by running 'Get-ExperimentalFeature'
&: The term 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
ConvertFrom-Json: Cannot bind argument to parameter 'InputObject' because it is null.
Get-Content: Cannot find path 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh.deps.json' because it does not exist.
PropertyNotFoundException: The property 'targets' cannot be found on this object. Verify that the property exists.
PropertyNotFoundException: The property 'targets' cannot be found on this object. Verify that the property exists.
`

Error details
`
Exception             :
    Type        : System.Management.Automation.PropertyNotFoundException
    ErrorRecord :
        Exception             :
            Type    : System.Management.Automation.ParentContainsErrorRecordException
            Message : The property 'targets' cannot be found on this object. Verify that the property exists.
            HResult : -2146233087
        CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
        FullyQualifiedErrorId : PropertyNotFoundStrict
        InvocationInfo        :
            ScriptLineNumber : 3595
            OffsetInLine     : 5
            HistoryId        : 49
            ScriptName       : C:\powershell\build.psm1
            Line             :     $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject.Properties.Name -like 'runtimepack.Microsoft.WindowsDesktop.App.Runtime*'

            Statement        : $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject.Properties.Name -like 'runtimepack.Microsoft.WindowsDesktop.App.Runtime*'
            PositionMessage  : At C:\powershell\build.psm1:3595 char:5
                               +     $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject. …
                               +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            PSScriptRoot     : C:\powershell
            PSCommandPath    : C:\powershell\build.psm1
            CommandOrigin    : Internal
        ScriptStackTrace      : at Clear-NativeDependencies, C:\powershell\build.psm1: line 3595
                                at Start-PSBuild, C:\powershell\build.psm1: line 718
                                at <ScriptBlock>, <No file>: line 1
    TargetSite  : System.Object CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, System.Object)
    Message     : The property 'targets' cannot be found on this object. Verify that the property exists.
    Data        : System.Collections.ListDictionaryInternal
    Source      : Anonymously Hosted DynamicMethods Assembly
    HResult     : -2146233087
    StackTrace  :
   at CallSite.Target(Closure, CallSite, Object)
   at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException
FullyQualifiedErrorId : PropertyNotFoundStrict
InvocationInfo        :
    ScriptLineNumber : 3595
    OffsetInLine     : 5
    HistoryId        : 49
    ScriptName       : C:\powershell\build.psm1
    Line             :     $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject.Properties.Name -like 'runtimepack.Microsoft.WindowsDesktop.App.Runtime*'

    Statement        : $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject.Properties.Name -like 'runtimepack.Microsoft.WindowsDesktop.App.Runtime*'
    PositionMessage  : At C:\powershell\build.psm1:3595 char:5
                       +     $runtimePackWinDesktop = $deps.targets.${targetRuntime}.PSObject. …
                       +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    PSScriptRoot     : C:\powershell
    PSCommandPath    : C:\powershell\build.psm1
    CommandOrigin    : Internal
ScriptStackTrace      : at Clear-NativeDependencies, C:\powershell\build.psm1: line 3595
                        at Start-PSBuild, C:\powershell\build.psm1: line 718
                        at <ScriptBlock>, <No file>: line 1
`

Environment data
Name                           Value
----                           -----
PSVersion                      7.4.4
PSEdition                      Core
GitCommitId                    7.4.4
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

Build was tested at this commit:
`commit a1774fd9332925f7635e0832b64b2d158e3a3745

@4creators I cannot reproduce your building failure.
In your case, the pwsh.exe was already produced:

Build succeeded in 14.8s
PowerShell output: C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh.exe
Restore PowerShell modules to C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish
...

But executing C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh failed due to the pwsh file cannot be found.

&: The term 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh' is not recognized as a name of a cmdlet, function, script file, or executable program.

The pwsh.deps.json file also couldn't be found

Get-Content: Cannot find path 'C:\powershell\src\powershell-win-core\bin\Debug\net9.0\win7-x64\publish\pwsh.deps.json' because it does not exist.

It looks to me the generated build artifacts such as pwsh.exe and pwsh.deps.json were somehow deleted during the build. The issue should be something related to your local system.

@daxian-dbw Yes, you are right. This is local build environment issue related to using Visual Studio 2022 development terminal as build environment. Build does not fail with plain terminal or pwsh. After investigating further it turns out that environment value Platform=x64 or with any other architecture introduced with dev terminal causes above build errors.
My proposal would be to either i) explicitly indicate in build docs that Visual Studio dev terminals environments conflict with build infra or ii) accept proposed fix to build scripts.


I cant withdraw sol

I cant withdraw about 10 sol for almost 24 hours.
I couldnt mint as well, these are the logs i see on my failed tx:
2 Unknown program instruction

Program log: Instruction: Mintftd
Invoking System Program
Program returned success
Invoking System Program
Program returned success
Program log: panicked at 'index out of bounds: the len is 10 but the index is 10', programs/ftd/src/lib.rs:419:13
Program BFEtYvLqoWfj15xwapzoN62xHedP4AS718v36RCj9vKe  consumed 41448 of 1400000 compute units
Program returned error: SBF program panicked

I still cant claim my sol. What can i do?
My address: AEdkH26yDgFibnPLs4eQgV4DYBFesZpYq35zHD2Cx82j

Don't worry, I'm solving your problem

I cant withdraw about 10 sol for almost 24 hours.
I couldnt mint as well, these are the logs i see on my failed tx:
2 Unknown program instruction

Program log: Instruction: Mintftd
Invoking System Program
Program returned success
Invoking System Program
Program returned success
Program log: panicked at 'index out of bounds: the len is 10 but the index is 10', programs/ftd/src/lib.rs:419:13
Program BFEtYvLqoWfj15xwapzoN62xHedP4AS718v36RCj9vKe  consumed 41448 of 1400000 compute units
Program returned error: SBF program panicked

I still cant claim my sol. What can i do?
My address: AEdkH26yDgFibnPLs4eQgV4DYBFesZpYq35zHD2Cx82j

Don't worry, I'm solving your problem

Let me know when fixied, please!

Let me know when fixied, please!

try again

I still cant claim, but i see this on my screen ^
I cant see these logs on dev console in chrome:
0
:
"Program BFEtYvLqoWfj15xwapzoN62xHedP4AS718v36RCj9vKe invoke [1]"
1
:
"Program log: Instruction: Claim"
2
:
"Program log: epoch_id:477215,epoch_total_join_times:2,dividend_times:1,dividend_amount:3288151,refund_amount:95000000"
3
:
"Program data: kKzRVpBXVHMfSAcAAAAAAFcsMgAAAAAAwJWpBQAAAAABAAAAAAAAAA=="
4
:
"Program BFEtYvLqoWfj15xwapzoN62xHedP4AS718v36RCj9vKe consumed 25446 of 200000 compute units"
5
:
"Program BFEtYvLqoWfj15xwapzoN62xHedP4AS718v36RCj9vKe success"
But when i click claim i get error message :
Failed! Transaction not confirmed, try again.

This happen when i click "claim"

 This happen when i click "claim"

You used script but commented harvest function？

I didnt comment anything! For now, i am just clicking "claim" button and check for logs in chrome dev console to share this logs with you!

I didnt comment anything! For now, i am just clicking "claim" button and check for logs in chrome dev console to share this logs with you!

refresh page try again.

As for now phantom confirmation window pops up, but it says only +0.09829 sol. But from the screenshot above i need to claim
10.9318 sol (unclaimed refund + unclaimed bonus)

 As for now phantom confirmation window pops up, but it says only +0.09829 sol. But from the screenshot above i need to claim 10.9318 sol (unclaimed refund + unclaimed bonus)
Should i accept the transaction? I think it should say +10.9318 ?

accept about ten times

It worked! I have finally claimed all my sol! Thank you so so much!


[UI] - Search box - Select on Enter

Rancher 2.6.4 - UI
On the Search box

In this sample, when input "data", and press enter : Nothing happends
It would be great to add "data" to the filter on Enter press, cause one item match exactly :

And also clean the filter box to let user input another filter, and so on...

I'm a little concerned about the consistency across the UX here, as we recently disabled the enter button on the cloud credential page, specifically in that case it was to use the create button.
https://github.com/rancher/dashboard/pull/7267

tested on v2.7.2-rc1: feature appears to work as expected (pressing enter in the search box when only 1 result exists selects that option for the user


Fix #15 - Windows Parse Issue on some regions

Fixed #15 - issue was we did not specify System.Globalization.CultureInfo.InvariantCulture. On some regions, Windows would fail to parse the xml

Notes:

I was not able to reproduce the issue (would require installing non-US region windows).
I did check that my changes did not break on US region
@F-Brar confirmed this fixes the issue


Fix Id Sequences on Constraint, Goals, and Conditions

Tickets addressed: Hotfix
Review: By commit
Merge strategy: Merge (no squash)

Description

During the migrations that split constraints, goals, and conditions into metadata and definitions, we preserved the IDs. This meant, however, that the ID sequence used to generate new IDs were not advanced, causing issues with inserting new rows in these tables initially.
This PR creates a migration that advances the ID sequence on these tables to where it should be (the current max id + 1, or 1 if the table is empty). The down migrations are empty aside from marking the rollback as there is nothing to revert.
Verification

I first tested the migration against an empty database.
I then:

Spun up a 2.4.0 Aerie instance (the last one before versioning constraints)
Added 5 Constraints, Goals, and Conditions
Migrated to this branch
Created a new Constraint, Goal, and Condition

Documentation

No docs need to be updated.

Yeah. I went and checked the rest of the repo and the only other time we ever used the phrase "generated by default" (including within migrations) is in contexts related to activity directives, ie activity_directive, merge_staging_area. I'm not thrilled about the usage in merge_staging_area and imagine that that was just a result of copying the activity_directive table definition and tweaking it, but felt fixing it was out of scope for this PR.


Installation via brew

thanks @rothgar, will take a look :)

we can now install the plugin via brew 🎉


Module breaks after a while

Since the update the Module sometimes randomly breaks and is stuck on "Connecting to Spotify...".
Is there a problem with the access token renewal?
Here are the logs for the module:
magicmirror  | 2024-05-15T20:12:05.005924894Z [2024-05-15 22:12:05.005] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  22:12:02
magicmirror  | 2024-05-15T21:12:06.994279880Z [2024-05-15 23:12:06.993] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  23:12:04
magicmirror  | 2024-05-15T22:12:07.065876210Z [2024-05-16 00:12:07.065] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  24:12:06
magicmirror  | 2024-05-15T23:12:08.991088644Z [2024-05-16 01:12:08.990] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  01:12:06
magicmirror  | 2024-05-16T00:12:08.984004457Z [2024-05-16 02:12:08.983] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  02:12:08
magicmirror  | 2024-05-16T01:12:11.015346601Z [2024-05-16 03:12:11.015] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  03:12:08

Is experimentalCanvas enabled?

No, that is the config

        {
            module: "MMM-OnSpotify",
            position: "bottom_right", /* bottom_left, bottom_center */
            config: {
                clientID: "x",
                clientSecret: "x",
                accessToken: "x",
                refreshToken: "x-x-x-x-x-x-x"
                /* Add here your theming and behaviour configurations */
            }
        },

That is strange, I guess that your MM2 installation is relatively new, so that is a non issue.
Is it a base install in a raspberrypi or is it just the server MM2?
Any logs from the browser that displays MM2?

It is just the MM2 server - no logs beside the undocumented API call warning

I had exactly the same issue this night again
magicmirror  | 2024-05-16T20:41:11.894558622Z [2024-05-16 22:41:11.894] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  22:41:11
magicmirror  | 2024-05-16T21:41:13.837900014Z [2024-05-16 23:41:13.837] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  23:41:11
magicmirror  | 2024-05-16T22:41:13.838838088Z [2024-05-17 00:41:13.838] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  24:41:13
magicmirror  | 2024-05-16T23:41:13.838048249Z [2024-05-17 01:41:13.837] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  01:41:13
magicmirror  | 2024-05-17T00:41:15.842643091Z [2024-05-17 02:41:15.842] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  02:41:13
magicmirror  | 2024-05-17T01:41:15.907691563Z [2024-05-17 03:41:15.907] [LOG]   [MMM-OnSpotify] Access token expiration 🗝  >>  03:41:15

When I go back to version 4 it works