feat: Use Auth.js (NextAuth v5)

Is your feature request related to a problem? Please describe.
Currently, the authentication setup in the project might lack the flexibility and security improvements available in the latest version of Auth.js (NextAuth v5). By not using the latest version, the project may also miss out on support for modern authentication standards and improved developer experience.
Describe the solution you'd like to see
Integrate Auth.js (NextAuth v5) into the project to handle authentication. This would involve updating the authentication middleware and configuration to leverage the new features and improvements offered by NextAuth v5, providing a more robust and flexible solution.
Describe alternate solutions
N/A
Additional information
No response

https://github.com/t3-oss/create-t3-app/issues/1979


Workflow: FreeBSD Current Builds Runner

For FreeBSD, there are two main branches that would need to be tested against: Current (13.3 and 14.1) and 2nd Tier (13.2 and 14.0). 2nd Tier is the equivalent of Ubuntu LTS and Current is the stable bleeding edge branch. None are binary backwards compatible but all get released in pairs around the same time, so there would be shifting every few months (based on what the runner supports), but this is ready unless you have issues with it or there are bugs.
Because FreeBSD runs as a vm inside of an Ubuntu vm, performance and compilation speed will take a hit, but the sdk builds should be fully testable by others on 14.1 64-bit. It’s also going to be mostly running in vm instead of using external runners for things like git checkout, ninja + cmake, etc. Until a builder is officially supported, these will be mostly ran directly in the vm.

That’s the issue I’ve been running into. ui_uiedit.h randomly fails to moc or gets missed when running on anything above a single core locally or with the runner. Not sure why it’s happening yet but know it’s exclusive to that header. I have most of tomorrow off so one possible solution is setting up caching and doing a single full build and then locking the build on one core. Incremental builds would be faster and this issue may exist for other CMake targets. Caching would speed up builds for all targets since there’s already quite a bit of rebuilding after commits are pushed.

I was attempting to be clever by setting up ccache in the top level CMake file but it's ignoring that, so it's going to be scripted directly in the run part of the workflow script. Might still be able to set them in that file for the other platforms since they're not running in an embedded vm of a vm. At least right now, consistent release SDK builds are coming.
The Github docs say the free cache is 500 MB, which is perfect because the full build cache (see the end of the Build log; I have it printing the current stats of the ccache directory, environment variables, etc) is just under 400 MB, so, if all else fails, whatever the last package built was, that would essentially swap out the cache and be the fastest build next time meaning that at least one of the CMake builds will be done early freeing resources for the others.

Partially worked. The environment variables are now being used. Hopefully, this next iteration will get caching working as intended. Almost there. :joy_cat:

Not finished yet but now have caching initially working. They’re mostly empty due to what are hopefully permissions quirks with the freebsd runner. That’s definitely my wheel house. 🤘

Won't have time to work on this this morning (running late for my job) but I've pulled in latest master and merged it and my current work into a new branch. There's some slight breakage with the QML updates but nothing too major on that front. If the Qt6 upgrade fixes the Moc issue (not fully sure how it works compared to Qt5's), setting up caching wouldn't be a fix but instead just a nice to have that could still be useful in the long run. Because I've started integrating the freebsd-vm runner code into the build system, once some hard coded parts are ironed out, I'll have the means to still test against different stable releases without worrying about taxing the CI build system too much for the other platforms.
I'm going to be perfectly frank: some of this is hunch and other parts of it are just from experience with different Unix platforms. Every piece of feedback remains top priority. I'm not super active on Discord in any servers but am in yours if you need to immediately get ahold of me; I'm blunt, forward, kind of dumb at times, but mostly jolly and very open to feedback. If you're working on something that affects what I'm working on and vice versa, feel free to ping me there and ask me to wait on any PRs if running them will be inconvenient due to timezone differences. Right now, I can only work in the early mornings and late at night here except for on Saturdays and Mondays now due to work schedule change. My early mornings will clash with your time and I can wait until I get midway through work and push PRs from my phone but will have to wait to work on feedback.

Up early working on this some. I have around an hour at most but the qml breakages are removed. I've also moved to Ninja from gmake for local builds. So far, the ui_uiedit.h moc bug hasn't shown up yet but will. :crying_cat_face:

Closing this due to a merge making it obsolete.


docs: add fixes after review

This PR gathers a few different reviewed topics:

Contributing: Clearifies more about response time, and quality of input.
Contributing: Adds section about translations and that English is primary
Development: Further improves contributions instructions for DEVELOPMENT.md
Readme: Adds an informal summary of the policy from wich this project originated
Some minor typos or adjustments.

Checklist

[x] My contributions and commit messages follows the style guidelines of this project
[x] I have made corresponding changes to the documentation
[x] New and existing unit tests pass locally with my changes
[x] The Pull Request has an informative and human-readable title
[x] Changes are limited to a single goal (avoid scope creep)
[x] Code can be automatically merged (no conflicts)
[x] I confirm that I have read any Contribution guidelines (CONTRIBUTING)
[x] I confirm that I wrote and/or have the right to submit the contents of my PR, by agreeing to the Developer Certificate of Origin, by adding a 'sign-off' to my commits

Thanks! (Will most likely do a little rebase from the codeowners-pr on this branch also.)


Formatting is broken

This extension works well, but the snippet added to the user snippet file has formatting errors.
The snippet is added to the end of the existing snippets, but it doesn't respect the existing indentation, it doesn't add a trailing comma to the previous snippet block and it has a trailing comma despite being the last block.

I'm attaching three files. My user snippet php.json before insertion, after insertion and the expected result. I gave them the .txt extension because it looks like you can't upload json. I hope this is good enough.
My bit of code was testing for proper escaping of php's $. You have that right. Almost no one handles that correctly.
Regards
after_insertion_php.txt
before_insertion_php.txt
expected_result_php.txt

OK, I understood.
I'll fix it in the next update.
Until the next update, please add a trainling comma for the second-to-last item and press ctrl+alt+F (ctrl+option+F, in Mac) to adjust the indentation.

I think the problem was solved in v0.2.2.
If you encountered a similar issue, feel free to reopen this issue.


0.9x: Image Passthrough

The functionality used to generally exist, but due to the shifting of RasterWizard to be more integral to images that guarantee was lost.
Many programs allow for image pre-processing including meerK40t but with the expansion of services like Imag-r (http://imag-r.com) we need overt support for images being set in passthrough mode. The preprocessing of data is largely a heavily lossy operation usually ending with dithering the data down to 2-bit images. After this is done it is no longer possible to process the image further. However the problem arises if you try. Trying to process an already processed image can absolutely cause serious problems for the image and image quality.
Passthrough mode images should allow you to set a size (which is directly countered with DPI) or set a DPI which overtly requires the image be an exact size. Rotations that are not exactly 1/4th turn (or multiples thereof) or flips could not be permitted. And such a mode should provide a guarentee that we won't touch one pixel of the original image but send it entirely nakedly to our background driver in a 1:1 mode.
Passthrough should set by default if an image is loaded in 2-bit.

Still relevant


error

yes have the same isuue any fix.
i just commented it but not helped it's just saying:-
e: D:\Software\Android studio\Flutter SDK.pub-cache\hosted\pub.dartlang.org\flutter_armod_widget-0.0.5\android\src\main\kotlin\com\phantomsxr\armodplugin\FlutterARMODWidgetController.kt: (196, 5): 'onUnityPlayerUnloaded' overrides nothing

Hi, Try pulling the git main branch again, we updated it to 2.0.0-p re.1 and it supports Flutter 3.0 now.
You must to upgrade your libs and framework.
A: How to upgrade?
Q: Go to ARFramework repor and download it replace your old libs or framework.

yes i have the same isuue as well any fix. i just commented it but not helped it's just saying:- e: D:\Software\Android studio\Flutter SDK.pub-cache\hosted\pub.dartlang.org\flutter_armod_widget-0.0.5\android\src\main\kotlin\com\phantomsxr\armodplugin\FlutterARMODWidgetController.kt: (196, 5): 'onUnityPlayerUnloaded' overrides nothing

Hi, Try pulling the git main branch again, we updated it to 2.0.0-p re.1 and it supports Flutter 3.0 now.


User defined header interpolation inconsistent around empty values

Title:  User defined header interpolation inconsistent around empty values
Description:
Envoy's mechanism for configuration specified user-defined headers (https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#config-http-conn-man-headers-custom-request-headers) is inconsistent in the case of variables that may or may not have a value.  This is specifically an issue when using the %UPSTREAM_METADATA(["namespace", "key"])% variable interpolation.  If a header is defined as only composed of that value, and the value does not exist, the header is not output.  However, if the header is a compound header (e.g. "prefix-%UPSTREAM_METADATA(["namespace", "key"])%-suffix") then the header is output regardless of whether or not the variable interpolation returns any text.
Relevant Links:
Source link to not outputting the header if the value interpolated is empty: https://github.com/envoyproxy/envoy/blob/master/source/common/router/header_parser.cc#L240
Source link to combination of headers which may have null values: https://github.com/envoyproxy/envoy/blob/master/source/common/router/header_formatter.h#L80

@curiouserrandy from a comment here: https://github.com/envoyproxy/envoy/pull/4016#issuecomment-409755614 it seems the current behaviour for processing a compound header when it gives empty string is OK for now. How do you think we will proceed with this "inconsistency"?

So if we wanted to fix this, I'd vote in favor of allowing empty header values rather than nuking the header if the value was empty.  But just explicitly documenting the current behavior is also fine by me--I was mostly filing this to call out a possible trip hazard in the API.

@curiouserrandy yeah IMO we should do a doc PR. WDYT?

Sure, that sounds good.  @dio, willing to take a swing at that?

@curiouserrandy sure. Let me have that. Thanks!

I think @gozali wants to take this.


fix GAE_MODULE fall-back to local hostname

We were sending undefined as the GAE_MODULE label.
@matthewloring ptal.

The change looks good, unfortunately, it looks like redis 2.3 -> 2.4 broke our hooks and is causing travis to go red. This may be the first instance where we need separate patching logic at the minor version level.

CI failure should be a flake. LGTM when it goes green.


Makefile for sparkctl

Makefile for building sparkctl
mainly for dev people with no golang knowledge/setup
please consider uploading the binaries to github releases

also, we cant use:
SPARK_OPERATOR_GOPATH=$GOPATH/src/github.com/GoogleCloudPlatform/spark-on-k8s-operator
as this interpolates at runtime with the host machine and we actually need the docker image internal go path


favicon for the website?

Logo as favicon: https://3.basecamp.com/5185891/buckets/23922789/uploads/5317146677

this is done.


[DC-533][DC-534] Revert "DC-531: Revert preview dataset and link to workspace (#3351)"

This reverts commit 004592f8a7af983cf741828653255ede616e3c3d.
I added permissions to scarlett.flowerpicker on the readable snapshot in both staging and alpha to fix the link-to-workspace test failures, and tested locally by updating my local config to point at alpha and running the link-to-workspace test against that local. The long term fix is captured in a TDR ticket (already filed and I don't have the ticket number handy)
I fixed the preview bug by wrapping our default case in _.toString. This is not ideal, but it gets a partial preview out the door and can be further improved to handle objects properly in a follow up.

@s-rubenstein can you answer @pshapiro4broad question about the toString fix?

@pshapiro4broad I missed committing it. :D


Add ru-RU to home template

Added russian traslation for main page
https://r208.tk/ for check this commit and click on "Русский"

Thanks!


Incorrect "Not all operations have an unique name" on 1.11.2

Describe the bug
1.11.2 is incorrectly stating "Not all operations have an unique name" when I attempt to run codegen; 1.8.3 was working fine.
To Reproduce
Codegen works fine on the Graphile Starter codegen-fine branch: https://github.com/graphile/starter/tree/codegen-fine
However, when we upgrade graphql-codegen from 1.8.3 to 1.11.2 we get the aforementioned error; see: https://github.com/graphile/starter/tree/codegen-bad which is one commit ahead of codegen-fine.
I've dug into this further; see "Additional context"
Running graphql-codegen results in:
 ✔ Parse configuration
  ❯ Generate outputs
    ❯ Generate index.tsx
      ✔ Load GraphQL schemas
      ✔ Load GraphQL documents
      ✖ Generate
        → Not all operations have an unique name: AddEmail

 Found 1 error

  ✖ index.tsx
    Not all operations have an unique name

    * AddEmail found in:

          -<EMAIL_ADDRESS>          -<EMAIL_ADDRESS>          -<EMAIL_ADDRESS>          -<EMAIL_ADDRESS>          -<EMAIL_ADDRESS>    Error: Not all operations have an unique name: AddEmail
        at validateDuplicateDocuments (/home/benjie/Dev/starter/node_modules/@graphql-codegen/core/index.cjs.js:200:1
5)
        at Object.codegen (/home/benjie/Dev/starter/node_modules/@graphql-codegen/core/index.cjs.js:59:9)
        at process (/home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:783:67)
        at Array.map (<anonymous>)
        at /home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:790:63
        at processTicksAndRejections (internal/process/task_queues.js:93:5)
        at async Task.task (/home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:582:17)
    Error: Not all operations have an unique name: AddEmail
        at validateDuplicateDocuments (/home/benjie/Dev/starter/node_modules/@graphql-codegen/core/index.cjs.js:200:1
5)
        at Object.codegen (/home/benjie/Dev/starter/node_modules/@graphql-codegen/core/index.cjs.js:59:9)
        at process (/home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:783:67)
        at Array.map (<anonymous>)
        at /home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:790:63
        at processTicksAndRejections (internal/process/task_queues.js:93:5)
        at async Task.task (/home/benjie/Dev/starter/node_modules/@graphql-codegen/cli/bin.js:582:17)

Expected behavior
Codegen should run as expected (since all my operations are uniquely named)
Environment:

OS: Ubuntu 18.04.3 LTS
NodeJS: v12.13.1

    "@graphql-codegen/add": "^1.11.2",
    "@graphql-codegen/cli": "^1.11.2",
    "@graphql-codegen/typescript": "^1.11.2",
    "@graphql-codegen/typescript-operations": "^1.11.2",
    "@graphql-codegen/typescript-react-apollo": "1.11.2"

Additional context
I investigated further using the Node debugger because this issue is bizarre. I ended up here:

Note that the rawSDL value for this entry has an import and mutation DeleteEmail; however the definitions entry contains an operation and a fragment, the operation is named AddEmail which is not sourced from this file. The imported fragment can be seen here but doesn't contain any operations:
fragment EmailsForm_UserEmail on UserEmail {
  id
  email
  isVerified
  isPrimary
  createdAt
}

Interestingly this fragment IS used by the AddEmail operation, so it looks like the re-used fragment is causing the file/operations to be interpretted incorrectly.

@dotansimha
seems like we do not get any Not all operations have an unique name errors at all, now.
v1.12.2 - generated everything with duplicated typings e.g. for react.
v1.9.1 - does not generate and prints the expected error

@KillerCodeMonkey You should probably raise that as a separate issue :+1:

@benjie how did you manage to get such a detailed error message in your console? I only get:
Generate outputs
  ❯ Generate to src/lib/graphql.tsx
    ✔ Load GraphQL schemas
    ✔ Load GraphQL documents
    ✖ Not all operations have an unique name: CreateGroup, AllGroups
Running lifecycle hook "afterStart" scripts...

I can't figure out why it wont generate my DeleteGroup mutation and why it thinks the above two are have been made more than once.

🤷

@MincePie can you try running codegen with env var DEBUG=1 graphql-codegen ?

and what version are you running @MincePie ?

if it is on the latest version of codegen I would recommend you create a new issue


Is there a definition about customizing response Model attributes ( response fileds filter )?

response Object of different endpoints ( even context ) may refer to the same Model, but needs different attributes of the Model, generally, we could return corresponding fileds/attributes by using fields filter or operation context , is there a way to define these in swagger ?

There isn't, mostly due to limitations of JSON Schema.


Same Name Services on Different Databases - Foxx Bug

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[x] 3.1.21

Mode:

[x] Single-Server

Storage-Engine:

[x] rocksdb

On this operating system:

[x] Linux

[x] CentOS 7 .rpm

Foxx
These are the steps to reproduce:

send a req to http://<IP_ADDRESS>:8529/_db/yabco/yabco-service/rpc
send a req to http://<IP_ADDRESS>:8529/_db/yabco-dev/yabco-service/rpc
send a req to http://<IP_ADDRESS>:8529/_db/yabco/yabco-service/rpc
the data is stored on yabco-dev instead of yabco
...

yabco-service on yabco, is running in production mode.
yabco-service on yabco-dev, is running in development mode.
0- create two services with mount points of /yabco-service on two different databases with different users, say yabco and yabco-dev.
---
To make sure its not from same name
To make sure that the error was not from me, I changed the second service name from yabco-service to yabco-service-dev.
now on yabco I have yabco-service
and on yabco-dev I have yabco-service-dev
UPDATE
Even changing the service name doesn't help!
I have to go and switch the service from prod to dev and again from dev to prod mode, so to make the data get stored in the correct Database!

You mentioned the following sequence of operations to reproduce the problem:

send a req to http://<IP_ADDRESS>:8529/_db/yabco/yabco-service/rpc
send a req to http://<IP_ADDRESS>:8529/_db/yabco-dev/yabco-service/rpc
send a req to http://<IP_ADDRESS>:8529/_db/yabco/yabco-service/rpc
the data is stored on yabco-dev instead of yabco

However, what is each request to "/yabco-service/rpc" supposed to do? Store a document in a collection? How is that collection accessed exactly (e.g. by what means and what code)?
Does the last line "the data is stored on yabco-dev instead of yabco" mean that for the third request the data is stored in "yabco-dev" whereas it should rather be stored in "yabco"? Or do yo refer to any data being stored in "yabco-dev" (which is probably expected as one of the above requests was sent to "yabco-dev".
Can you please elaborate?

I'll explain a situation that happens from time to time,
we are working on two separate domains, say: A.com and B.com
A.com is our production site(yabco), and B.com is the DEV site (yabco-dev).
When I login to one of them, a session with a token is inserted into the database.
I have a user, named ali, on both yabco and yabco-dev.
I try to login into A.com using ali,
Login is successful, the page is redirecting to the dashboard, but suddenly goes back to login page,
what's happening?
I check the token stored in the cookie, it is not stored in yabco, it is stored in yabco-dev!!!
I go to services pane, find the yabco-service, switch it to development mode, then switch it back to production mode.
now I go back and login again, now I'm successfully in the dashboard page.

I've also added some logging to my services both on yabco and yabco-dev.
when I'm on the A.com, I receive all the logs coming from yabco.
so there's no wrong routing in the proxy server.

I captured a video to better demonstrate the situation:
https://youtu.be/YxsD8xIEO_c

@p30arena That you're seeing the same problem even when you rename the service leads me to believe there's something else going on with your setup.
Can you please try the following:

Disable the A.com:80 server/proxy and perform the requests against A.com:10000

Disable the A.com:10000 server/proxy and perform the requests against A.com:80

There are numerous reasons I don't think the described behaviour could occur in ArangoDB itself (especially the part where documents end up in the wrong database) and I'm fairly confident the problematic behaviour originates either in the browser (e.g. AJAX against the wrong domain) or in a misconfigured proxy.
However if this really is an issue in ArangoDB it's difficult to diagnose it further without a minimal test case we can explore. Based on your description I would assume the problem to persist in the following scenario:

Install a service in (non-system) database A
Install an identical service in (non-system) database B
Switch service in B to development
Perform request against service in A
Request is erroneously handled by service in B
Switch service in B to production
Perform request against service in A again
Request is handled by service in A as expected

@mpv1989 Can you maybe give the above steps a try? I know development mode affects the routing, so I wouldn't completely rule out there's something wonky going on inside Foxx.

@pluma I did what you asked for, the issue is not related to the proxy, as I said before I placed logs on both proxies to check if anything goes wrong!
Please take note that yabco-service is running in production mode but yabco-service-dev is running in development mode.
here's the video for the POC:
https://youtu.be/uji90IXQBG4

@pluma is it related to the Manifest??
I checked, and I saw that in the service manifest, the name is yabco for both services (problem with copy pasting...).
This is the manifest for both the yabco-service and yabco-service-dev:
{
    "name": "yabco",
    "version": "0.0.0",
    "description": "YABCO SERVICE",
    "engines": {
        "arangodb": "^3.0.0"
    },
    "author": "Ali",
    "license": "Apache2",
    "main": "index.js",
    "scripts": {
        "setup": "scripts/setup.js",
        "teardown": "scripts/teardown.js"
    },
    "tests": "test/**/*.js"
}

I bet its related, because when switch from prod to dev and back, the service reads the manifest again.
the names conflict.
why doesn't it throw an Error?!

I changed the manifests and again did the steps that @pluma asked.
[root@ip42 yabco]# cat /var/lib/arangodb3-apps/_db/yabco/yabco-service/APP/manifest.json
{
    "main": "index.js",
    "scripts": {
        "setup": "scripts/setup.js",
        "teardown": "scripts/teardown.js"
    }
}
[root@ip42 yabco]# cat /var/lib/arangodb3-apps/_db/yabco-dev/yabco-service-dev/APP/manifest.json
{
    "main": "index.js",
    "scripts": {
        "setup": "scripts/setup.js",
        "teardown": "scripts/teardown.js"
    }
}

The problem still exists, I'm confused 😕

Okay, that's pretty disturbing, especially because neither the db nor the mount paths are the same. The "name" field in the manifest should be irrelevant as it's mostly cosmetical.
Thanks for confirming this with a minimal example. Can you clarify how you access the collection? Do you use the arangodb.db object or the module.context.collection method?

@pluma
const db = require('@arangodb').db;
const usersCollection = db._collection('users');

@p30arena : is the assignment
const usersCollection = db._collection('users');

done outside out the routes?
If yes, then the following may happen:

the script is loaded when first accesses. This will bind the collection "users" from the currently accessed database to variable usersCollection.
when the scripts is accessed for a different database but has been cached already, the const assignment will not happen again. Instead only the route function is executed, but it will refer to the already assigned variable, which will then point to the wrong collection.
The solution for this is to make the variable assignment for collections in each route.

@jsteemann that's exactly what we do
function createModuleHashTable(path) {
	return fs.listTree(path)
	.filter(e => e.endsWith('.js'))
	.reduce((a, b) => {
		a.set(
			b
			.replace(/\//g, '_')
			.slice(0, -3)
			.toLowerCase(),
			require(fs.join(path, b))
		);
		return a;
	}, new Map());
}

then in the route we call the function.
If thats the case, it must be a bug related to Foxx, they are two services on two different databases, with two separate memory allocations, why should my objects interfere?

@jsteemann That seems unlikely. Foxx service files (including bundled dependencies) are cached per service per db, not globally like other JS files. It's not necessary to create the collection reference per route, in fact none of the Foxx examples do this.
@p30arena wait, you're redefining something on the global object? That might be the problem. As both of your services define the same global variable, only one of them can win. This will always be the one mounted last, so it'll usually be the development service because that is loaded on every access whereas the production service is only loaded once per context on first access.
In other words: all instances of the service (in the same context but across different databases) will share the reference global.import_model of one instance of the service. So you're effectively exposing access to one service's collections to all instances of the same service on any database. This is why your documents end up in weird places.
This also explains why the mount path is irrelevant. I suggest you don't pollute the global object. The kind of meta-programming you're doing with dynamic requires in a lookup table is already a bit dubious (e.g. your code will likely fail on Windows systems) but if you really want something "global" to all your service files but not the database, consider using module.context.service instead of global. This is the service instance.

We should probably add a warning about modifying "global" in the documentation somewhere. Probably in the incompatibility caveat section (which currently lives in the chapter on dependencies but should probably go somewhere else).

@pluma that's weird, why should the global var be accessible to all of the services?!
Ok thats not a bug from your point of view, but thats a Defect from my point of view.

@pluma I fucked everything by using this line:
global = module.context.service;
Its really hard to change the codes, no workaround?
😄

The "global" object is global. There's no way around this.
FWIW the recommended approach would be to extract your model map into a separate module you can require wherever you need it and then use that. Polluting the global namespace is generally discouraged in any JavaScript environment as far as I'm aware.

I placed all global vars in exp;
module.context.service.m_tools = exp;

module.context.service.lts = `var {
	m_ok,
	...
	UNIQUE_CONSTRAINT_ERROR,
	NO_CREDIT,
} = module.context.service.m_tools;`;

now in another module, I use this code to define vars:
eval(module.context.service.lts);
console.log(NO_CREDIT);

I really think you should be putting these in modules and require them as needed. I also think you shouldn't use eval: https://stackoverflow.com/questions/86513/why-is-using-the-javascript-eval-function-a-bad-idea
Using module.context.service or global is a hack. It's not a good way to design your application.

ArangoDB 3.2.2 containing this bugfix is available for download - thanks for reporting.
Closing.


synapse, regen azure-synapse-artifacts with new spec commit

fix https://github.com/Azure/azure-sdk-for-java/issues/27497
code change due to updated spec is commit: https://github.com/Azure/azure-sdk-for-java/pull/27498/commits/d0a2f68d77dc257f930081a03a7a3ddadd3cd816
prepare release for azure-synapse-artifacts 1.0.0-beta.9 as HLC.
Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API changes have been detected in com.azure:azure-analytics-synapse-artifacts. You can review API changes here

Same description in readme seems not correct from day1

General
Azure Synapse Artifacts clients raise exceptions. For example, if you try to retrieve an artifact after it is deleted a 404 error is returned, indicating the resource was not found. In the following snippet, the error is handled gracefully by catching the exception and displaying additional information about the error.
try {
    PipelineResource deletedPipeline = client.getPipeline(pipelineName);
} catch (ResourceNotFoundException e) {
    System.out.println(e.getMessage());
}

There is no ResourceNotFoundException in code.

/check-enforcer evaluate


'gmt' comflict

Hello,
I am running into problems using GMT (Generic Mapping Tools) because gmt is being used as an alias for git mergetools.
How can I disable the alias for git merge tools so I can access GMT?

If you want to disable alias, then unalias gmt. Otherwise, You could also call \gmt to call actual program not an alias.

@nuimk Thanks. I've added that to my configuration. Before your reply I had aliased gmt. This simplifies a script I've written.


Improve line spacing (fix #196)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Incorrect domain pattern on step 5b

I hit an issue with the integration and it was due to the details on step 5b which states:
b. In the Identifier (Entity ID) text box, type a value using the following pattern: <subdomain>.zendesk.com
Steps A and C indicate the use of the scheme is required within the config value and in my scenario the https was required to work
If you don't include the https:// you get the error message along the lines of "Misconfigured application. This could be due to one of the following: the client has not listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration...... Client app ID: 8e17306b-5fc3-4b73-8e4c-76ec4156b163"

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

ID: 16ae6014-a5f6-03f3-4ad4-4425cfe5b6ca
Version Independent ID: 1d3d0543-89f7-180a-e52a-b5668a314e6a
Content: Tutorial: Microsoft Entra SSO integration with Zendesk - Microsoft Entra ID
Content Source: docs/identity/saas-apps/zendesk-tutorial.md
Service: entra-id
Sub-service: saas-apps
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@richard-northumbria
Thanks for your feedback! We will investigate and update as appropriate.

@richard-northumbria, thanks for raising the issue!!
we're updating the document with correct Identifier value.
#please-close


unable to get dependency BellSoft Liberica NIK.

the output log:
...
18:05:34  [INFO]     [creator]     Running build command
18:05:34  [INFO]     [creator]
18:05:34  [INFO]     [creator]     Paketo Buildpack for BellSoft Liberica 11.0.0
18:05:34  [INFO]     [creator]       https://github.com/paketo-buildpacks/bellsoft-liberica
18:05:34  [INFO]     [creator]       Build Configuration:
18:05:34  [INFO]     [creator]         $BP_JVM_JLINK_ARGS           --no-man-pages --no-header-files --strip-debug --compress=1  configure custom link arguments (--output must be omitted)
18:05:34  [INFO]     [creator]         $BP_JVM_JLINK_ENABLED        false                                                        enables running jlink tool to generate custom JRE
18:05:34  [INFO]     [creator]         $BP_JVM_TYPE                 JRE                                                          the JVM type - JDK or JRE
18:05:34  [INFO]     [creator]         $BP_JVM_VERSION              21                                                           the Java version
18:05:34  [INFO]     [creator]       Launch Configuration:
18:05:34  [INFO]     [creator]         $BPL_DEBUG_ENABLED           false                                                        enables Java remote debugging support
18:05:34  [INFO]     [creator]         $BPL_DEBUG_PORT              8000                                                         configure the remote debugging port
18:05:34  [INFO]     [creator]         $BPL_DEBUG_SUSPEND           false                                                        configure whether to suspend execution until a debugger has attached
18:05:34  [INFO]     [creator]         $BPL_HEAP_DUMP_PATH                                                                       write heap dumps on error to this path
18:05:34  [INFO]     [creator]         $BPL_JAVA_NMT_ENABLED        true                                                         enables Java Native Memory Tracking (NMT)
18:05:34  [INFO]     [creator]         $BPL_JAVA_NMT_LEVEL          summary                                                      configure level of NMT, summary or detail
18:05:34  [INFO]     [creator]         $BPL_JFR_ARGS                                                                             configure custom Java Flight Recording (JFR) arguments
18:05:34  [INFO]     [creator]         $BPL_JFR_ENABLED             false                                                        enables Java Flight Recording (JFR)
18:05:34  [INFO]     [creator]         $BPL_JMX_ENABLED             false                                                        enables Java Management Extensions (JMX)
18:05:34  [INFO]     [creator]         $BPL_JMX_PORT                5000                                                         configure the JMX port
18:05:34  [INFO]     [creator]         $BPL_JVM_HEAD_ROOM           0                                                            the headroom in memory calculation
18:05:34  [INFO]     [creator]         $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               the number of loaded classes in memory calculation
18:05:34  [INFO]     [creator]         $BPL_JVM_THREAD_COUNT        250                                                          the number of threads in memory calculation
18:05:34  [INFO]     [creator]         $JAVA_TOOL_OPTIONS                                                                        the JVM launch flags
18:05:34  [INFO]     [creator]         Using Java version 17 extracted from MANIFEST.MF
18:05:34  [INFO]     [creator]       BellSoft Liberica NIK 17.0.13: Contributing to layer
18:05:34  [INFO]     [creator]         Downloading from https://github.com/bell-sw/LibericaNIK/releases/download/23.0.6+1-17.0.13+12/bellsoft-liberica-vm-core-openjdk17.0.13+12-23.0.6+1-linux-amd64.tar.gz
18:14:55  [INFO]     [creator]     unable to invoke layer creator
18:14:55  [INFO]     [creator]     unable to get dependency BellSoft Liberica NIK. see DEBUG log level
18:14:55  [INFO]     [creator]     Timer: Builder ran for 9m13.332373658s and ended at 2024-11-19T10:14:47Z
18:14:55  [INFO]     [creator]     ERROR: failed to build: exit status 1
18:14:55  [INFO] ------------------------------------------------------------------------
18:14:55  [INFO] BUILD FAILURE
18:14:55  [INFO] ------------------------------------------------------------------------
18:14:55  [INFO] Total time:  09:54 min
18:14:55  [INFO] Finished at: 2024-11-19T10:14:47Z
18:14:55  [INFO] ------------------------------------------------------------------------
18:14:55  [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.2.0:build-image (default-cli) on project authorization-server: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:3.2.0:build-image failed: Builder lifecycle 'creator' failed with status code 51 -> [Help 1]
...

this pom:
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <docker>
            <builderRegistry>
                <username>***</username>
                <password>***</password>
                <url>https://harbor.oak.net.cn:8443</url>
                <email>***</email>
            </builderRegistry>
        </docker>
        ...
        <image>
            <builder>harbor.oak.net.cn:8443/paketobuildpacks/builder-jammy-tiny</builder>
            <runImage>harbor.oak.net.cn:8443/paketobuildpacks/run-jammy-tiny</runImage>
            <verboseLogging>true</verboseLogging>
            ...

            <bindings>
                <binding>
                    ${buildRootDir}/bindings:/platform/bindings
                </binding>
            </bindings>
            <buildCache>
                <volume>
                    <name>cache-${project.artifactId}.build</name>
                </volume>
            </buildCache>
            <launchCache>
                <volume>
                    <name>cache-${project.artifactId}.launch</name>
                </volume>
            </launchCache>
        </image>
    </configuration>
</plugin>

springboot version is:3.2.0

Last year was a good year at work, what should I do to fix my build?

Try the link directly. Can you download it in your browser? As a sanity check, the link works for me.
If you're on a corporate network, make sure that you've configured proxy settings ,if those are required. See https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.examples.builder-configuration and https://paketo.io/docs/howto/configuration/#proxy-configuration.
If you're in CI, maybe just retry. Maybe the network was slow or flaky.
The build took a pretty long time for now having done much work, so I suspect that the request is either never connecting and hanging for some reason or connecting and downloading very slowly. We do offer configurable timeouts, so you could try adjusting those too.

BP_DIALER_TIMEOUT (default 6)
BP_DIALER_KEEP_ALIVE (default 60)
BP_TLS_HANDSHAKE_TIMEOUT (default 5)
BP_RESPONSE_HEADER_TIMEOUT (default 5)
BP_EXPECT_CONTINUE_TIMEOUT (default 1)

Times in seconds. These settings correspond to the Go HTTP Client settings of the same name, which are explained well here -> https://stackoverflow.com/a/72358623/1585136

Thank you very much, @dmikusa. It was indeed due to network access in the CI environment that the download of the JDK failed. I have added a Mapping obtained from the disk as you suggested. I noticed that these mappings may need regular updates as they do not always use a fixed version.

Thank you again.

I have added a Mapping obtained from the disk as you suggested. I noticed that these mappings may need regular updates as they do not always use a fixed version.

Yes, the mappings are done with a hash which ties them to a specific binary. When something changes, like a new version, you need to generate a new mapping.
Mirrors are similar, in that you have to pull and update your mirror when new binaries are available.


🐛 [cloud_firestore_odm] sub-collections models generation which are a collection on its own is failing

Bug report
Describe the bug
Sub-collection models from separate dart file does not seems to be working fine in the root model.
Steps to reproduce
Steps to reproduce the behavior:
The root model is below.
import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:cloud_firestore_odm/cloud_firestore_odm.dart';
import 'package:equatable/equatable.dart';
import 'package:json_annotation/json_annotation.dart';

import 'group.dart';

part 'app_user.g.dart';

@JsonSerializable(converters: firestoreJsonConverters)
class AppUser extends Equatable {
  const AppUser({
    required this.id,
    required this.name,
    required this.email,
    required this.photoUrl,
    required this.joinDate,
    this.birthDate,
    this.country,
    this.age = 0,
    this.isOnline = false,
    this.lastOnline,
    this.isAdmin = false,
    this.isActive = true,
    this.gender,
    this.tokens,
  });

  final String id;
  final String name;
  final String email;
  final String photoUrl;
  final Timestamp joinDate;
  final Timestamp? birthDate;
  final int age;
  final bool? isAdmin;
  final bool? isOnline;
  final Timestamp? lastOnline;
  final bool? isActive;
  final String? country;
  final String? gender;
  final List<String>? tokens;

  factory AppUser.fromJson(Map<String, dynamic> json) =>
      _$AppUserFromJson(json);

  Map<String, dynamic> toJson() => _$AppUserToJson(this);

  @override
  List<Object?> get props => [name, email, photoUrl];
}

@Collection<AppUser>('users')
@Collection<AppUser>(
  'users/*/friends',
  prefix: 'Friends',
)
@Collection<Group>('users/*/groups')
final usersRef = AppUserCollectionReference();

The other model which has its own collection and also its part of the root model is shared below.
import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:cloud_firestore_odm/cloud_firestore_odm.dart';
import 'package:equatable/equatable.dart';
import 'package:json_annotation/json_annotation.dart';

part 'group.g.dart';

@JsonSerializable(converters: firestoreJsonConverters)
class Group extends Equatable {
  const Group({
    required this.id,
    required this.name,
    required this.description,
    this.image,
    required this.createdTime,
    this.isPinned = false,
    this.isActive = true,
    this.isPrivate = false,
    this.usersCount = 0,
  });

  final String id;
  final String name;
  final String description;
  final String? image;
  final Timestamp createdTime;
  final bool? isPinned;
  final bool? isActive;
  final bool? isPrivate;
  final int usersCount;

  factory Group.fromJson(Map<String, dynamic> json) => _$GroupFromJson(json);

  Map<String, dynamic> toJson() => _$GroupToJson(this);

  @override
  List<Object?> get props => [name];
}

@Collection<Group>('groups')
final groupsRef = GroupCollectionReference();

Below is my build.yml content.
targets:
  $default:
    builders:
      cloud_firestore_odm_generator:
        enabled: true
        generate_for:
          include:
            - lib/*
            - lib/**
            - test_driver/integration/*
            - test_driver/integration/**/*
      json_serializable:
        enabled: true
        generate_for:
          include:
            - lib/*
            - lib/**
            - test_driver/integration/*
            - test_driver/integration/**/*
        options:
          create_field_map: true
          explicit_to_json: true
          create_factory: true
      source_gen|combining_builder:
        options:
          ignore_for_file:
            - 'type=lint'

Below is the exception after the generation.

Expected behavior
The models should be generated without any issues.

Some more details on my use case.. Group is a collection on its own. and it's also a sub-collection under AppUsers
/users
/groups
/users/*/groups

Thanks for the report.
/cc @rrousselGit

The ability to define the class for a Firestore sub-collection in a separate file would be nice. Let's say we have two models, User and MedicalRecord.
Case 1 | Collections defined in one file. Generator runs without errors, but the generated file contains the error undefined Name '_$MedicalRecordFieldMap'.
part 'user.g.dart';

@Collection<User>('users')
@Collection<MedicalRecord>('users/*/medical_records')
@firestoreSerializable
class User {
    String name;
    int age;

    User(
        this.name,
        this.age,
     );
}

part 'medical_record.g.dart';

@firestoreSerializable
class MedicalRecord {
    Timestamp date;
    String description;

    MedicalRecord(
        this.date,
        this.description,
     );
}

Case 2 | Collections defined in two separate files. Generator doesn't run without errors
part 'user.g.dart';

@Collection<User>('users')
@firestoreSerializable
class User {
    String name;
    int age;

    User(
        this.name,
        this.age,
     );
}

part 'medical_record.g.dart';

@Collection<MedicalRecord>('users/*/medical_records')
@firestoreSerializable
class MedicalRecord {
    Timestamp date;
    String description;

    MedicalRecord(
        this.date,
        this.description,
     );
}

It would be awesome if one of the two options would work in the future, as one file with the classes for all sub-collections can get pretty large and complex. It would be neat to have one file for each class!

About this, I don't think that's something that can fully be supported.
The ODM relies on private code generated by json_serializable for a bunch of things, with more to come.
We could have a nice error message about it. But supporting it, I'm not sure.

Case 1 | Collections defined in one file. Generator runs without errors, but the generated file contains the error undefined Name '_$MedicalRecordFieldMap'.

That's your mistake. The documentation mentions that a specific json_serializable flag needs to be enabled for the ODM to handle json_serializable
See https://github.com/firebase/flutterfire/blob/master/packages/cloud_firestore_odm/doc/defining-models.md#defining-models. Cf the   createFieldMap: true, in @JsonSerializable

As mentioned, I doubt there's a reasonable solution to this problem.
Maybe this could be done better once we have metaprogramming. Otherwise, this would require a very large refactoring of json_serializable for this.


Code Cleanup

Cleanup code
simplify raspberry-config and other scripts, etc
create subdirectories to artwork, scripts, config files, etc

Resolved by #135 and should be closed.


Purge GSA sandboxes for users that did not intend to create them or left the organization

In order to right size our platform sandboxes for GSA users, we want to remove all sandboxes that are unintended or the user has left GSA.
Acceptance Criteria

[ ] Given our GSA sandbox org, all the spaces will be used and owned for valid reason by current GSA employees.

Security considerations

Helps to minimize platform footprint

Implementation sketch
[links to background notes, sketches, and/or relevant documentation

[X] A list of sandbox spaces from #1432
[ ] Purge all sandboxes belonging to GSA employees that are no longer at the agency
[ ] Reach out to any possible current GSA employees that have sandboxes unintentionally, confirm, and purge the sandbox.

This ticket is stale and not a priority for now
It is also very difficult to purge sandboxes for those who are no longer GSA employees without an API or data source to definitively list active GSA employees

We may later want to create a follow-on ticket for making sandbox-purge a feature for the CG-UI team. One customer told us they may be required to show that a user's resources have been terminated when they leave the org (not just their ability to authentication).


npm install node-red-contrib-oled    does not install latest code (0.1.0)

HendrikRoth
Although code has been updated to "version": "0.1.0" which incidental works very well .... Node-Red Manage Palette still says "0.0.2" is latest update and if you install via Manage Palette or npm install node-red-contrib-oled you still get "0.0.2" not "0.1.0"

updated all repositories, now everything is on 0.1.0


Error python setup.py build_ext --inplace

Hello,
I have an issue building the project.
This is the command line and the generated error message.
Thanks in advance,
Sebastian
system:
win10
CUDA 9.0
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2017 NVIDIA Corporation Built on Fri_Sep__1_21:08:32_Central_Daylight_Time_2017 Cuda compilation tools, release 9.0, V9.0.176
MSVC
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved.
(no environmental variables)
Pytorch 1.0.1
(installed via PIP)
Error Messages:
when i run python setup.py build_ext --inplace
... running build_ext C:\python36\lib\site-packages\torch\utils\cpp_extension.py:184: UserWarning: Error checking compiler version for cl: [WinError 2] Das System kann die angegebene Datei nicht finden warnings.warn('Error checking compiler version for {}: {}'.format(compiler, error)) building 'pointnet2._ext' extension
when i run python setup.py install
File "C:\python36\lib\distutils\command\build_ext.py", line 448, in build_extensions self._build_extensions_serial() File "C:\python36\lib\distutils\command\build_ext.py", line 473, in _build_extensions_serial self.build_extension(ext) File "C:\python36\lib\site-packages\setuptools\command\build_ext.py", line 199, in build_extension _build_ext.build_extension(self, ext) File "C:\python36\lib\distutils\command\build_ext.py", line 558, in build_extension target_lang=language) File "C:\python36\lib\distutils\ccompiler.py", line 717, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "C:\python36\lib\distutils_msvccompiler.py", line 501, in link build_temp = os.path.dirname(objects[0]) IndexError: list index out of range

I have not tested building this on Windows and I don't have access to a windows machine to debug this on, so I can't be of much help.  If you figure out what needs to change to get things to build on windows, I'd happily accept that PR.

I also faced issue in setup.py when building setup.py
running build_ext
building 'pointnet2._ext' extension
gcc -pthread -B /mnt/disks/user/anaconda3/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/mnt/disks/user/anaconda3/lib/python3.6/site-packages/torch/lib/include -I/mnt/disks/user/anaconda3/lib/python3.6/site-packages/torch/lib/include/TH -I/mnt/disks/user/anaconda3/lib/python3.6/site-packages/torch/lib/include/THC -I/usr/local/cuda/include -I/mnt/disks/user/anaconda3/include/python3.6m -c pointnet2/_ext-src/src/bindings.cpp -o build/temp.linux-x86_64-3.6/pointnet2/_ext-src/src/bindings.o -O2 -Ipointnet2/_ext-src/include -DTORCH_EXTENSION_NAME=_ext -D_GLIBCXX_USE_CXX11_ABI=0 -std=c++11
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
In file included from pointnet2/_ext-src/src/bindings.cpp:1:0:
pointnet2/_ext-src/include/ball_query.h:2:10: fatal error: torch/extension.h: No such file or directory
#include <torch/extension.h>
^~~~~~~~~~~~~~~~~~~
compilation terminated.
error: command 'gcc' failed with exit status 1

What version of pytorch are you using?  master requires pytorch>=1.0.  If you are on pytorch>=1.0, then there seems to be an issue with your pytorch install and I'd suggest re-installing.

Any update on this issue? I've been having the same one with pytorch=1.2 and I've already tried resetting up my anaconda environment twice to reset my pytorch installation

Same issue here with pytorch=1.1, any suggestions?

Same problem pytorch 1.4
build_temp = os.path.dirname(objects[0])
IndexError: list index out of range
in msvccompiler.py line 502

I have a problem. The detailes are followed.
I am try python setup.py build_ext --inplace, that ran into a bud
RuntimeError: Error compiling objects for extension
Ubuntu 18.04, cuda 11.0    pytorch 1.7.0,
who knows why

I have a problem. The detailes are followed.
I am try python setup.py build_ext --inplace, that ran into a bud
RuntimeError: Error compiling objects for extension
Ubuntu 18.04, cuda 11.0 pytorch 1.7.0,
who knows why

I have the same problem as you,  have you solve it?


Force pex to use a wheel of a library but resolve other dependencies from index

I'm trying to build a pex executable but ensure that the library is resolved from a custom index, not PyPi. One risky way to do is to switch places --index-url and --extra-index-url:
pex my-package -o my-executable.pex --index-url https://my.custom.index --extra-index-url https://pypi.org/simple

but I'm thinking of a better way of simply using my-package.whl like I can do with pip in a venv:
pip install my-package.whl

is there any way for me to do the same with pex?

You should have just tried it! This should work, ~same as Pip.
pex my-package.whl -o my-executable.pex

thanks John! It does work 😊
just to not get embarresed too much, I did try, just in the wrong way:
pex -f my-package.whl -o my-executable.pex

😀

Aha - ok. So, -f / --find-links should also work just like Pip. It needs to be a directory containing a flat set of wheels.
So this-too should work[^1]:
mkdir fl-repo
ln -s ../my-package.whl fl-repo/
pex -f fl-repo my-package -o my-executable.pex

[^1]: Well, maybe work. This re-introduces the question of index precedence. Does Pip resolve from --find-links repos before PyPI? Who knows - they have never guaranteed ordering of resolution when there are multiple indexes / find-links repos in play and that ordering has in face changed over time.

@maxkoretskyi  is your package local? If so, more simply you can just:
pex . -o my-executable.pex

Here I assume you're in the project's root directory. If not pex path/to/project -o my-executable.pex works too. Pex understands how to build your project into a wheel no matter you project build system.

thanks, pretty much answered, just a few clarifications

pex -f fl-repo my-package -o my-executable.pex

I was trying to avoid specifying my-package b/c I wasn't sure if pex/pip prefers index over -f
also, when I specify path to a wheel like this mydir/k-*.whl:
pex mydir/k-*.whl -o f.pex

is the expansion supposed to work or not?

I was trying to avoid specifying my-package b/c I wasn't sure if pex/pip prefers index over -f

Yeah, you're right to be unsure: https://github.com/pex-tool/pex/issues/2567#user-content-fnref-1-c269f1869919f2e2e04982d9887dcad6

is the expansion supposed to work or not?

Well, the expansion is handled by your shell; so its up to your shell! But for bash anyway, the answer is yes.

that's a good addition, thanks! so it can do the same as python -m build

Yes. Just like Pip can. Pex should treat all requirements (positional arguments) on the CLI just like Pip.

Awesome, thanks!

But you should try it!

PS. I do try everything before asking, just probably in a different way :)

Did pex mydir/k-*.whl -o f.pex fail?

no, it's good! once I got confirmation from you, I found where I got confused... it's probably too late here

Ok, excellent. Thanks @maxkoretskyi!


using .code in switch expressions breaks highlighting

Seems similar to the #23
Using [CHARACTER].code inside switch expressions breaks highlighting
Minimal example I came up with
class TSBug {
	public static function main() {
		var ch = "b".code;
		switch (ch) {
			case "b".code:
				trace("bug");
			case "s".code:
				trace("bug");
			case "x".code:
				trace("bug");
		}
	}
}

Removing .code makes highlighting work again

This should be fixed with v0.9.0


[CPU] Do not generate vector.gather for contiguous loads

The tensor.extract below has a contiguous memory access pattern along the adjacent dimension. We should improve the analysis to generate a contiguous vector load:
// -----// IR Dump After LLVMCPUTensorPad (iree-llvmcpu-tensor-pad) //----- //
func.func @forward_dispatch_19_batch_matmul_1024x384x384x64_f32() {
  %c64 = arith.constant 64 : index
  %c128 = arith.constant 128 : index
  %c8 = arith.constant 8 : index
  %c32 = arith.constant 32 : index
  %c384 = arith.constant 384 : index
  %c1024 = arith.constant 1024 : index
  %c100761600 = arith.constant 100761600 : index
  %c201424896 = arith.constant 201424896 : index
  %c0 = arith.constant 0 : index
  %c503414784 = arith.constant 503414784 : index
  %cst = arith.constant 0.000000e+00 : f32
  %c16 = arith.constant 16 : index
  %cst_0 = arith.constant 1.000000e+00 : f32
  %cst_1 = arith.constant -3.40282347E+38 : f32
  %cst_2 = arith.constant 8.000000e+00 : f32
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c100761600) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>>
  %1 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c201424896) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>>
  %2 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>>
  %3 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c503414784) : !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
  %4 = flow.dispatch.tensor.load %2, offsets = [0, 0, 0, 0], sizes = [64, 1, 1, 384], strides = [1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>> -> tensor<64x1x1x384xf32>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  %workgroup_id_y = hal.interface.workgroup.id[1] : index
  %workgroup_count_y = hal.interface.workgroup.count[1] : index
  %workgroup_id_z = hal.interface.workgroup.id[2] : index
  %workgroup_count_z = hal.interface.workgroup.count[2] : index
  scf.for %arg0 = %workgroup_id_z to %c1024 step %workgroup_count_z {
    %5 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_id_y]
    %6 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_count_y]
    scf.for %arg1 = %5 to %c384 step %6 {
      %7 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_id_x]
      %8 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_count_x]
      scf.for %arg2 = %7 to %c384 step %8 {
        %9 = flow.dispatch.tensor.load %3, offsets = [%arg0, %arg1, %arg2], sizes = [1, 128, 128], strides = [1, 1, 1] : !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>> -> tensor<1x128x128xf32>
        %10 = flow.dispatch.tensor.load %0, offsets = [%arg0, %arg1, 0], sizes = [1, 128, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>> -> tensor<1x128x64xf32>
        %11 = flow.dispatch.tensor.load %1, offsets = [%arg0, 0, %arg2], sizes = [1, 64, 128], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>> -> tensor<1x64x128xf32>
        %12 = scf.for %arg3 = %c0 to %c128 step %c8 iter_args(%arg4 = %9) -> (tensor<1x128x128xf32>) {
          %13 = scf.for %arg5 = %c0 to %c128 step %c32 iter_args(%arg6 = %arg4) -> (tensor<1x128x128xf32>) {
            %extracted_slice = tensor.extract_slice %10[0, %arg3, 0] [1, 8, 64] [1, 1, 1] : tensor<1x128x64xf32> to tensor<1x8x64xf32>
            %extracted_slice_3 = tensor.extract_slice %11[0, 0, %arg5] [1, 64, 32] [1, 1, 1] : tensor<1x64x128xf32> to tensor<1x64x32xf32>
            %extracted_slice_4 = tensor.extract_slice %arg6[0, %arg3, %arg5] [1, 8, 32] [1, 1, 1] : tensor<1x128x128xf32> to tensor<1x8x32xf32>
            %14 = linalg.fill {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 128, 128], [1, 8, 32], [0, 0, 0], [0, 0, 0]]>} ins(%cst : f32) outs(%extracted_slice_4 : tensor<1x8x32xf32>) -> tensor<1x8x32xf32>
            %15 = scf.for %arg7 = %c0 to %c64 step %c16 iter_args(%arg8 = %14) -> (tensor<1x8x32xf32>) {
              %extracted_slice_5 = tensor.extract_slice %extracted_slice[0, 0, %arg7] [1, 8, 16] [1, 1, 1] : tensor<1x8x64xf32> to tensor<1x8x16xf32>
              %extracted_slice_6 = tensor.extract_slice %extracted_slice_3[0, %arg7, 0] [1, 16, 32] [1, 1, 1] : tensor<1x64x32xf32> to tensor<1x16x32xf32>
              %padded = tensor.pad %extracted_slice_5 nofold low[0, 0, 0] high[0, 0, 0] {
              ^bb0(%arg9: index, %arg10: index, %arg11: index):
                tensor.yield %cst : f32
              } : tensor<1x8x16xf32> to tensor<1x8x16xf32>
              %padded_7 = tensor.pad %extracted_slice_6 nofold low[0, 0, 0] high[0, 0, 0] {
              ^bb0(%arg9: index, %arg10: index, %arg11: index):
                tensor.yield %cst : f32
              } : tensor<1x16x32xf32> to tensor<1x16x32xf32>
              %17 = linalg.batch_matmul {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 128, 128, 0], [1, 8, 32, 0], [0, 0, 0, 16], [0, 0, 0, 0]]>} ins(%padded, %padded_7 : tensor<1x8x16xf32>, tensor<1x16x32xf32>) outs(%arg8 : tensor<1x8x32xf32>) -> tensor<1x8x32xf32>
              scf.yield %17 : tensor<1x8x32xf32>
            }
            %16 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} outs(%15 : tensor<1x8x32xf32>) attrs =  {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 128, 128], [1, 8, 32], [0, 0, 0], [0, 0, 0]]>} {
            ^bb0(%out: f32):
              %17 = linalg.index 0 : index
              %18 = affine.apply affine_map<(d0, d1) -> (d0 + d1)>(%arg0, %17)
              %19 = arith.divui %18, %c16 : index
              %20 = linalg.index 2 : index
              %21 = affine.apply affine_map<(d0, d1, d2) -> (d0 + d1 + d2)>(%arg2, %20, %arg5)
              %extracted = tensor.extract %4[%19, %c0, %c0, %21] : tensor<64x1x1x384xf32>
              %22 = arith.subf %cst_0, %extracted : f32
              %23 = arith.mulf %22, %cst_1 : f32
              %24 = arith.divf %out, %cst_2 : f32
              %25 = arith.addf %24, %23 : f32
              linalg.yield %25 : f32
            } -> tensor<1x8x32xf32>
            %inserted_slice = tensor.insert_slice %16 into %arg6[0, %arg3, %arg5] [1, 8, 32] [1, 1, 1] : tensor<1x8x32xf32> into tensor<1x128x128xf32>
            scf.yield %inserted_slice : tensor<1x128x128xf32>
          }
          scf.yield %13 : tensor<1x128x128xf32>
        }
        flow.dispatch.tensor.store %12, %3, offsets = [%arg0, %arg1, %arg2], sizes = [1, 128, 128], strides = [1, 1, 1] : tensor<1x128x128xf32> -> !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
      }
    }
  }
  return
}

// -----// IR Dump After GenericVectorization (iree-codegen-generic-vectorization) //----- //
func.func @forward_dispatch_19_batch_matmul_1024x384x384x64_f32() {
  %cst = arith.constant dense<384> : vector<1x8x32xindex>
  %cst_0 = arith.constant dense<8.000000e+00> : vector<1x8x32xf32>
  %cst_1 = arith.constant dense<-3.40282347E+38> : vector<1x8x32xf32>
  %cst_2 = arith.constant dense<1.000000e+00> : vector<1x8x32xf32>
  %cst_3 = arith.constant dense<true> : vector<1x8x32xi1>
  %cst_4 = arith.constant dense<[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]> : vector<32xindex>
  %cst_5 = arith.constant dense<16> : vector<1x8x32xindex>
  %cst_6 = arith.constant dense<0.000000e+00> : vector<1x8x32xf32>
  %c1 = arith.constant 1 : index
  %c64 = arith.constant 64 : index
  %c128 = arith.constant 128 : index
  %c8 = arith.constant 8 : index
  %c32 = arith.constant 32 : index
  %c384 = arith.constant 384 : index
  %c1024 = arith.constant 1024 : index
  %c100761600 = arith.constant 100761600 : index
  %c201424896 = arith.constant 201424896 : index
  %c0 = arith.constant 0 : index
  %c503414784 = arith.constant 503414784 : index
  %cst_7 = arith.constant 0.000000e+00 : f32
  %c16 = arith.constant 16 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c100761600) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>>
  %1 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c201424896) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>>
  %2 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>>
  %3 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c503414784) : !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
  %4 = flow.dispatch.tensor.load %2, offsets = [0, 0, 0, 0], sizes = [64, 1, 1, 384], strides = [1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>> -> tensor<64x1x1x384xf32>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  %workgroup_id_y = hal.interface.workgroup.id[1] : index
  %workgroup_count_y = hal.interface.workgroup.count[1] : index
  %workgroup_id_z = hal.interface.workgroup.id[2] : index
  %workgroup_count_z = hal.interface.workgroup.count[2] : index
  scf.for %arg0 = %workgroup_id_z to %c1024 step %workgroup_count_z {
    %5 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_id_y]
    %6 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_count_y]
    scf.for %arg1 = %5 to %c384 step %6 {
      %7 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_id_x]
      %8 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_count_x]
      scf.for %arg2 = %7 to %c384 step %8 {
        %9 = flow.dispatch.tensor.load %3, offsets = [%arg0, %arg1, %arg2], sizes = [1, 128, 128], strides = [1, 1, 1] : !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>> -> tensor<1x128x128xf32>
        %10 = flow.dispatch.tensor.load %0, offsets = [%arg0, %arg1, 0], sizes = [1, 128, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>> -> tensor<1x128x64xf32>
        %11 = flow.dispatch.tensor.load %1, offsets = [%arg0, 0, %arg2], sizes = [1, 64, 128], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>> -> tensor<1x64x128xf32>
        %12 = scf.for %arg3 = %c0 to %c128 step %c8 iter_args(%arg4 = %9) -> (tensor<1x128x128xf32>) {
          %13 = scf.for %arg5 = %c0 to %c128 step %c32 iter_args(%arg6 = %arg4) -> (tensor<1x128x128xf32>) {
            %extracted_slice = tensor.extract_slice %10[0, %arg3, 0] [1, 8, 64] [1, 1, 1] : tensor<1x128x64xf32> to tensor<1x8x64xf32>
            %extracted_slice_8 = tensor.extract_slice %11[0, 0, %arg5] [1, 64, 32] [1, 1, 1] : tensor<1x64x128xf32> to tensor<1x64x32xf32>
            %extracted_slice_9 = tensor.extract_slice %arg6[0, %arg3, %arg5] [1, 8, 32] [1, 1, 1] : tensor<1x128x128xf32> to tensor<1x8x32xf32>
            %14 = vector.transfer_write %cst_6, %extracted_slice_9[%c0, %c0, %c0] {in_bounds = [true, true, true]} : vector<1x8x32xf32>, tensor<1x8x32xf32>
            %15 = scf.for %arg7 = %c0 to %c64 step %c16 iter_args(%arg8 = %14) -> (tensor<1x8x32xf32>) {
              %extracted_slice_10 = tensor.extract_slice %extracted_slice[0, 0, %arg7] [1, 8, 16] [1, 1, 1] : tensor<1x8x64xf32> to tensor<1x8x16xf32>
              %extracted_slice_11 = tensor.extract_slice %extracted_slice_8[0, %arg7, 0] [1, 16, 32] [1, 1, 1] : tensor<1x64x32xf32> to tensor<1x16x32xf32>
              %32 = vector.create_mask %c1, %c8, %c16 : vector<1x8x16xi1>
              %33 = vector.transfer_read %extracted_slice_10[%c0, %c0, %c0], %cst_7, %32 {in_bounds = [true, true, true]} : tensor<1x8x16xf32>, vector<1x8x16xf32>
              %34 = vector.create_mask %c1, %c16, %c32 : vector<1x16x32xi1>
              %35 = vector.transfer_read %extracted_slice_11[%c0, %c0, %c0], %cst_7, %34 {in_bounds = [true, true, true]} : tensor<1x16x32xf32>, vector<1x16x32xf32>
              %36 = vector.transfer_read %arg8[%c0, %c0, %c0], %cst_7 {in_bounds = [true, true, true]} : tensor<1x8x32xf32>, vector<1x8x32xf32>
              %37 = vector.contract {indexing_maps = [affine_map<(d0, d1, d2, d3) -> (d0, d1, d3)>, affine_map<(d0, d1, d2, d3) -> (d0, d3, d2)>, affine_map<(d0, d1, d2, d3) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel", "reduction"], kind = #vector.kind<add>} %33, %35, %36 : vector<1x8x16xf32>, vector<1x16x32xf32> into vector<1x8x32xf32>
              %38 = vector.transfer_write %37, %arg8[%c0, %c0, %c0] {in_bounds = [true, true, true]} : vector<1x8x32xf32>, tensor<1x8x32xf32>
              scf.yield %38 : tensor<1x8x32xf32>
            }
            %16 = vector.transfer_read %15[%c0, %c0, %c0], %cst_7 {in_bounds = [true, true, true]} : tensor<1x8x32xf32>, vector<1x8x32xf32>
            %17 = vector.broadcast %arg0 : index to vector<1x8x32xindex>
            %18 = arith.divui %17, %cst_5 : vector<1x8x32xindex>
            %19 = vector.broadcast %arg2 : index to vector<32xindex>
            %20 = arith.addi %19, %cst_4 : vector<32xindex>
            %21 = vector.broadcast %arg5 : index to vector<32xindex>
            %22 = arith.addi %20, %21 : vector<32xindex>
            %23 = arith.muli %18, %cst : vector<1x8x32xindex>
            %24 = vector.broadcast %22 : vector<32xindex> to vector<1x8x32xindex>
            %25 = arith.addi %24, %23 : vector<1x8x32xindex>
            %26 = vector.gather %4[%c0, %c0, %c0, %c0] [%25], %cst_3, %cst_6 : tensor<64x1x1x384xf32>, vector<1x8x32xindex>, vector<1x8x32xi1>, vector<1x8x32xf32> into vector<1x8x32xf32>
            %27 = arith.subf %cst_2, %26 : vector<1x8x32xf32>
            %28 = arith.mulf %27, %cst_1 : vector<1x8x32xf32>
            %29 = arith.divf %16, %cst_0 : vector<1x8x32xf32>
            %30 = arith.addf %29, %28 : vector<1x8x32xf32>
            %31 = vector.transfer_write %30, %arg6[%c0, %arg3, %arg5] {in_bounds = [true, true, true]} : vector<1x8x32xf32>, tensor<1x128x128xf32>
            scf.yield %31 : tensor<1x128x128xf32>
          }
          scf.yield %13 : tensor<1x128x128xf32>
        }
        flow.dispatch.tensor.store %12, %3, offsets = [%arg0, %arg1, %arg2], sizes = [1, 128, 128], strides = [1, 1, 1] : tensor<1x128x128xf32> -> !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
      }
    }
  }
  return
}

Repro:
hal.executable public @forward_dispatch_19 {
  hal.executable.variant public @system_elf_x86_64, target = <"llvm-cpu", "system-elf-x86_64", {cpu = "cascadelake", cpu_features = "+cmov,+mmx,+popcnt,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+avx,+avx2,+fma,+avx512f,+bmi,+bmi2,+aes,+pclmul,+avx512vl,+avx512bw,+avx512dq,+avx512cd,+avx512vnni,+adx,+clflushopt,+clwb,+cx16,+cx8,+crc32,+f16c,+fsgsbase,+fxsr,+invpcid,+lzcnt,+movbe,+pku,+prfchw,+rdrnd,+rdseed,+sahf,+x87,+xsave,+xsavec,+xsaveopt,+xsaves", data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", native_vector_size = 64 : index, target_triple = "x86_64-unknown-linux-elf", ukernels = true}> {
    hal.executable.export public @forward_dispatch_19_batch_matmul_1024x384x384x64_f32 ordinal(0) layout(#hal.pipeline.layout<push_constants = 0, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>) {
    ^bb0(%arg0: !hal.device):
      %x, %y, %z = flow.dispatch.workgroup_count_from_slice
      hal.return %x, %y, %z : index, index, index
    }
    builtin.module {
      func.func @forward_dispatch_19_batch_matmul_1024x384x384x64_f32() {
        %c100761600 = arith.constant 100761600 : index
        %c201424896 = arith.constant 201424896 : index
        %c0 = arith.constant 0 : index
        %c503414784 = arith.constant 503414784 : index
        %cst = arith.constant 0.000000e+00 : f32
        %c16 = arith.constant 16 : index
        %cst_0 = arith.constant 1.000000e+00 : f32
        %cst_1 = arith.constant -3.40282347E+38 : f32
        %cst_2 = arith.constant 8.000000e+00 : f32
        %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c100761600) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>>
        %1 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c201424896) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>>
        %2 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>>
        %3 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c503414784) : !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
        %4 = flow.dispatch.tensor.load %0, offsets = [0, 0, 0], sizes = [1024, 384, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x384x64xf32>> -> tensor<1024x384x64xf32>
        %5 = flow.dispatch.tensor.load %1, offsets = [0, 0, 0], sizes = [1024, 64, 384], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1024x64x384xf32>> -> tensor<1024x64x384xf32>
        %6 = flow.dispatch.tensor.load %2, offsets = [0, 0, 0, 0], sizes = [64, 1, 1, 384], strides = [1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<64x1x1x384xf32>> -> tensor<64x1x1x384xf32>
        %7 = tensor.empty() : tensor<1024x384x384xf32>
        %8 = linalg.fill ins(%cst : f32) outs(%7 : tensor<1024x384x384xf32>) -> tensor<1024x384x384xf32>
        %9 = linalg.batch_matmul ins(%4, %5 : tensor<1024x384x64xf32>, tensor<1024x64x384xf32>) outs(%8 : tensor<1024x384x384xf32>) -> tensor<1024x384x384xf32>
        %10 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d1, d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%9 : tensor<1024x384x384xf32>) outs(%7 : tensor<1024x384x384xf32>) {
        ^bb0(%in: f32, %out: f32):
          %11 = linalg.index 0 : index
          %12 = arith.divui %11, %c16 : index
          %13 = linalg.index 2 : index
          %extracted = tensor.extract %6[%12, %c0, %c0, %13] : tensor<64x1x1x384xf32>
          %14 = arith.subf %cst_0, %extracted : f32
          %15 = arith.mulf %14, %cst_1 : f32
          %16 = arith.divf %in, %cst_2 : f32
          %17 = arith.addf %16, %15 : f32
          linalg.yield %17 : f32
        } -> tensor<1024x384x384xf32>
        flow.dispatch.tensor.store %10, %3, offsets = [0, 0, 0], sizes = [1024, 384, 384], strides = [1, 1, 1] : tensor<1024x384x384xf32> -> !flow.dispatch.tensor<writeonly:tensor<1024x384x384xf32>>
        return
      }
    }
  }
}

iree-compile -output-format=vm-bytecode -iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-triple=x86_64-unknown-linux-elf -iree-llvmcpu-target-cpu=cascadelake  module_forward_dispatch_19.mlir

FYI: @banach-space

Thanks for this repro!
This is not a 1-D contiguous load and such loads are currently marked as gather load: getTensorExtractMemoryAccessPattern. This shouldn't be too difficult to support.
-Andrzej

Is there something that needs to be done here?

Is there something that needs to be done here?

Apologies, I dropped the ball there :( Thanks for the reminder - I should have some spare cycles in the next week or two to properly triage this.

I was thinking about the right place to do this.
The current set of patterns lower this
func.func @gather_test(%base: memref<8xi32>, %pass_thru: vector<4xi32>) -> vector<4xi32> {
  %true = arith.constant 1 : i1
  %c0 = arith.constant 0 : index

  %cst = arith.constant dense<[0, 1, 2, 3]> : vector<4xindex>
  %mask = vector.broadcast %true : i1 to vector<4xi1>

  %0 = vector.gather %base[%c0][%cst], %mask, %pass_thru : memref<8xi32>, vector<4xindex>, vector<4xi1>, vector<4xi32> into vector<4xi32>
  return %0 : vector<4xi32>
}

 mlir-opt %s --test-vector-gather-lowering --canonicalize gives
func.func @gather_test(%arg0: memref<8xi32>, %arg1: vector<4xi32>) -> vector<4xi32> {
    %c3 = arith.constant 3 : index
    %c2 = arith.constant 2 : index
    %c1 = arith.constant 1 : index
    %c0 = arith.constant 0 : index
    %0 = vector.load %arg0[%c0] : memref<8xi32>, vector<1xi32>
    %1 = vector.extract %0[0] : i32 from vector<1xi32>
    %2 = vector.insert %1, %arg1 [0] : i32 into vector<4xi32>
    %3 = vector.load %arg0[%c1] : memref<8xi32>, vector<1xi32>
    %4 = vector.extract %3[0] : i32 from vector<1xi32>
    %5 = vector.insert %4, %2 [1] : i32 into vector<4xi32>
    %6 = vector.load %arg0[%c2] : memref<8xi32>, vector<1xi32>
    %7 = vector.extract %6[0] : i32 from vector<1xi32>
    %8 = vector.insert %7, %5 [2] : i32 into vector<4xi32>
    %9 = vector.load %arg0[%c3] : memref<8xi32>, vector<1xi32>
    %10 = vector.extract %9[0] : i32 from vector<1xi32>
    %11 = vector.insert %10, %8 [3] : i32 into vector<4xi32>
    return %11 : vector<4xi32>
  }

Do you think we can potentially have a pattern for lowering vector.gather and vector.scatter to vector.load/vector.maskedload and vector.store/vector.maskedstore (with larger output vector sizes) whenever the index vector has values in unit progression?
This should also help other kinds of lowerings where vector.scatter/vector.gather is generated by default.
I can help by creating a patch for this in the upstream if you think this is a good idea.

@banach-space , If you haven't started working on this already, I'd like to help by creating a patch for it during my spare time.
I am thinking of starting with generating vector.transfer_read for the following minimal example
func.func @example_check(%arg0: tensor<80x16xf32>, %extracted_slice : tensor<4x4xf32>) -> tensor<4x4xf32> {
  %1 = linalg.generic {
    indexing_maps = [affine_map<(d0, d1) -> (d0, d1)>],
    iterator_types = ["parallel", "parallel"]
  } outs(%extracted_slice : tensor<4x4xf32>) {
  ^bb0(%out: f32):
    %2 = linalg.index 0 : index
    %3 = linalg.index 1 : index
    %extracted = tensor.extract %arg0[%2, %3] : tensor<80x16xf32>
    linalg.yield %extracted : f32
  } -> tensor<4x4xf32>
  return %1 : tensor<4x4xf32>
}

which currently gets lowered to
func.func @example_check(%arg0: tensor<80x16xf32>, %arg1: tensor<4x4xf32>) -> tensor<4x4xf32> {
    %cst = arith.constant dense<[0, 1, 2, 3]> : vector<4xindex>
    %cst_0 = arith.constant dense<true> : vector<4x4xi1>
    %cst_1 = arith.constant dense<0.000000e+00> : vector<4x4xf32>
    %c0 = arith.constant 0 : index
    %cst_2 = arith.constant dense<16> : vector<4x4xindex>
    %0 = vector.broadcast %cst : vector<4xindex> to vector<4x4xindex>
    %1 = arith.muli %0, %cst_2 : vector<4x4xindex>
    %2 = vector.transpose %1, [1, 0] : vector<4x4xindex> to vector<4x4xindex>
    %3 = vector.broadcast %cst : vector<4xindex> to vector<4x4xindex>
    %4 = arith.addi %3, %2 : vector<4x4xindex>
    %5 = vector.gather %arg0[%c0, %c0] [%4], %cst_0, %cst_1 : tensor<80x16xf32>, vector<4x4xindex>, vector<4x4xi1>, vector<4x4xf32> into vector<4x4xf32>
    %6 = vector.transfer_write %5, %arg1[%c0, %c0] {in_bounds = [true, true]} : vector<4x4xf32>, tensor<4x4xf32>
    return %6 : tensor<4x4xf32>
  }

Hi @meshtag , thanks for looking into this and apologies for not responding earlier - I was a bit overwhelmed with other activities.

@banach-space, I was having a look at the memory access pattern code you attached above, shouldn't this be vector<1x2x4xi32> or vector<2x1x4xi32> or am I missing out on something crucial?

Note that that method analyses tensor.extract Ops - at that level there are no vectors. There are also no n-D tensors, hence "vector" rather than "tensor" in:
//    * an n-D vector, like`tensor<1x2x4xi32` or`tensor<2x1x4xi32>"

Naming is hard :/ (I will send a very small update that will hopefully disambiguate things).
As for the original issue, this is the root cause leading to gather loads:
          %11 = linalg.index 0 : index
          %12 = arith.divui %11, %c16 : index
          %13 = linalg.index 2 : index
          %extracted = tensor.extract %6[%12, %c0, %c0, %13] : tensor<64x1x1x384xf32>

Specifically, %12 = arith.divui %11, %c16 : index. That's a constant for 16 iterations in the leading dim, but then it goes up by 1. That's not really a contiguous access :( It's not clear to me that the vectoriser would ever be able to do anything clever here.
Instead of trying to fix this in the vectoriser, we should tile the following operation before vectorisation:
%10 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d1, d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%9 : tensor<1024x384x384xf32>) outs(%7 : tensor<1024x384x384xf32>) {
        ^bb0(%in: f32, %out: f32):
          %11 = linalg.index 0 : index
          %12 = arith.divui %11, %c16 : index
          %13 = linalg.index 2 : index
          %extracted = tensor.extract %6[%12, %c0, %c0, %13] : tensor<64x1x1x384xf32>
          %14 = arith.subf %cst_0, %extracted : f32
          %15 = arith.mulf %14, %cst_1 : f32
          %16 = arith.divf %in, %cst_2 : f32
          %17 = arith.addf %16, %15 : f32
          linalg.yield %17 : f32
        } -> tensor<1024x384x384xf32>

@dcaballe WDYT?

@banach-space , If you haven't started working on this already, I'd like to help by creating a patch for it during my spare time.
I am thinking of starting with generating vector.transfer_read for the following minimal example

You are proposing to extend the vectoriser so that it can generate contiguous loads for reading n-D vectors  - 2D in your example. TBH, it's not obvious to me whether that would help for this specific issue. But I might be missing something. Do you have any other example where this would be helpful?
@dcaballe If you agree that the access pattern in your example is indeed a gather load, then I suggest closing this and to continue the discussion on contiguous loads of n-D vectors elsewhere (perhaps https://github.com/llvm/llvm-project/pull/76436).

Naming is hard :/ Here's very small update that will hopefully disambiguate things - https://github.com/llvm/llvm-project/pull/76797.

Thanks!

You are proposing to extend the vectoriser so that it can generate contiguous loads for reading n-D vectors - 2D in your example. TBH, it's not obvious to me whether that would help for this specific issue. But I might be missing something. Do you have any other example where this would be helpful?

I did not intend to solve this issue completely with that PR (and I agree that the change would not really benefit this case atm). To me, it seemed like the next simplest case (in continuation to what exists already) where we can try to get vector.transfer_read instead of vector.gather. There is a scenario in one of my downstream projects where we would benefit from that change directly. It's still a work in progress though.


backport of #2684 in stable-3.1

backport of #2684 in stable-3.1

jenkins test luminous-ansible2.4-docker_cluster

jenkins test dev-ansible2.4-centos7_cluster

jenkins test luminous-ansible2.4-docker_cluster_collocation

jenkins test luminous-ansible2.4-ooo_collocation

jenkins test luminous-ansible2.4-centos7_cluster


feat: add github summary integration

Close https://github.com/lacework/lw-scanner-action/issues/51
Summary
Github Summary is a simple way to expose the results of your pipeline to developers in a pull request context.
How did you test this change?
I've added a new pipeline which test it.
https://github.com/jycamier/lw-scanner-action/actions/runs/5392578473

Issue
https://github.com/lacework/lw-scanner-action/issues/51

Is there anything blocking this from being merged?

Just merged and will release. Thank for the contribution.

Okay, so we need to revert this change as we can not parse the exit code of the actually lw-scanner anymore. Exit code is overwritten by the pipe to tee.

Indeed. Sorry. I'll fix it in a few hours.


fix error: Ambiguous method overloading for method java.io.File#.

Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
    [class java.lang.String]
    [class java.net.URI]

用的是最新版吗？


now works with Components that accept Observable as children

Hi just wanted to submit PR related to this issue https://github.com/FormidableLabs/radium/issues/508

This is probably a good start. We could also get fancy and wrap the subscribe to apply Radium to any elements emitted.

subscribe isn't that universal, it seems that each FRP library uses different naming (bacon is onValue, for instance). But maybe this is good enough, since many people use RxJS.

This one seems stalled out, going to close it. We can revisit in the future.


Errors with path aliases, possible weird loading of tsconfig/jsconfig files

Hi,
Unfortunately I can't make a reproduction trigger the same problem as our main repo, but this repo should give an idea of our setup: https://github.com/jonasclement/volar-complex-repo
Basically:

The root directory is a legacy, AngularJS frontend
The "vue" directory is our new vue/vite frontend, which is the only one Volar should be affecting

Volar version: 2.0.5
VSCode version: 1.87.0
In our main repository, inside the vue directory, any aliased import a la @/something or @components/something.vue gets a Cannot find module '@/something' or its corresponding type declarations. ts-plugin(2307).
However, saving any of the project's tsconfig.json or jsconfig.json files will cause these to go away until the next TS server restart, with Intellisense and type checking still working perfectly. However, syntax highlighting for components in templates is broken, as these are the color of standard HTML tags rather than the color a component would normally have.
What can we do to resolve this?

I solved downgrading VSCode Vue - Official extension to 1.8.27.
Otherwise it seems you need to upgrade your project TS version to 5.0 but i didn't try.

Our project (the one in the vue directory in the linked repro) is using TypeScript 5.3, so that doesn't seem to be the factor. We have downgraded to 1.8.27 for now as well.

It seems normal to me. What does the error look like in your screen? Sharing your system info may help reproduce the problem (from the Help: About command)

VScode was entirely ignoring intellisense on my template tags. No components, no variables.  TS is 5.0.4 in package and tsc version is 5.3.3, so that did not help.
downgrading to 1.8.27 solved for me as well

I solved downgrading VSCode Vue - Official extension to 1.8.27 (I updated it to 2.0). Otherwise it seems you need to upgrade your VUE project TS version to 5.0 but i didn't try.

There is no error, there is just no intellisense on template tags.
but the extra info is here:
Version: 1.87.0
Commit: 019f4d1419fbc8219a181fab7892ebccf7ee29a2
Date: 2024-02-27T23:42:51.279Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 23.3.0

CPUs
Apple M1 Pro (8 x 24)

GPU Status
2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled

Load (avg)
2, 2, 3

Memory (System)
16.00GB (0.70GB free)

Process Argv
--crash-reporter-id fa627f66-1463-482a-bd30-f583aa38e810

Screen Reader
no

VM
0%

Extension
Author (truncated)
Version

monokai-charcoal-high-contrast
74t
3.4.0

go-outliner
766
0.1.21

pug
ama
1.0.1

preview-pdf
ana
1.0.0

alignment
ann
0.3.0

markdown-preview-github-styles
bie
2.0.3

vscode-tailwindcss
bra
0.10.5

cyber77-vscode
Cod
0.0.21

nuxt-vscode
cpr
0.0.6

language-postcss
cpy
1.1.0

dbclient-jdbc
cwe
1.3.4

vscode-mysql-client2
cwe
7.0.9

vscode-eslint
dba
2.4.4

pug-formatter
duc
0.6.0

gitlens
eam
14.8.2

EditorConfig
Edi
0.16.4

vsc-material-theme
Equ
34.3.1

vsc-material-theme-icons
equ
3.5.0

prettier-vscode
esb
10.1.0

copilot
Git
1.172.0

copilot-chat
Git
0.13.0

vscode-github-actions
git
0.26.2

vscode-pull-request-github
Git
0.82.0

go
gol
0.41.1

google-cloud-spanner-driver
goo
0.4.1

cloudcode
goo
2.5.0

terraform
has
2.29.4

vscode-position
jtr
1.1.2

vsc-python-indent
Kev
1.18.0

nodejs-repl
los
0.5.15

dotenv
mik
1.0.1

vscode-docker
ms-
1.29.0

vscode-kubernetes-tools
ms-
1.3.15

debugpy
ms-
2024.2.0

isort
ms-
2023.10.1

python
ms-
2024.2.1

vscode-pylance
ms-
2024.2.3

jupyter
ms-
2024.2.0

jupyter-keymap
ms-
1.1.2

jupyter-renderers
ms-
1.0.17

vscode-jupyter-cell-tags
ms-
0.1.8

vscode-jupyter-slideshow
ms-
0.1.5

remote-containers
ms-
0.348.0

cpptools
ms-
1.19.5

makefile-tools
ms-
0.8.22

vscode-typescript-next
ms-
5.5.20240304

vsliveshare
ms-
1.0.5918

go-doc
msy
1.0.1

sqltools
mtx
0.28.1

autodocstring
njp
0.6.1

vscode-versionlens
pfl
1.9.2

material-icon-theme
PKi
4.34.0

polacode
pnp
0.3.4

fabric8-analytics
red
0.9.2

java
red
1.28.1

vscode-xml
red
0.26.1

vscode-yaml
red
1.14.0

format-code-action
roh
0.1.0

vscode-scss-formatter
sib
3.0.0

vscode-stylelint
sty
1.3.0

even-better-toml
tam
0.19.2

intellicode-api-usage-examples
Vis
0.2.8

vscodeintellicode
Vis
1.2.30

vscode-java-debug
vsc
0.56.2

vscode-java-dependency
vsc
0.23.5

vscode-java-pack
vsc
0.25.15

vscode-java-test
vsc
0.40.1

vscode-maven
vsc
0.44.0

vscode-icons
vsc
12.7.0

volar
Vue
1.8.27

jinja
who
0.0.8

markdown-all-in-one
yzh
3.6.2

vscode-proto3
zxh
0.5.5

I had a similar problem but noticed a difference between a new project and my existing project. I had followed the direction from the extension to enable the builtin TS server, and remove the deprecated Vue extensions. I then had the same problems as described. I then tried a new project, and it worked fine. I had then noticed a difference between the two environments, my project was using tsconfig.node.json when viewing Vue files, whereas the new project used tsconfig.app.json. I then tried removing some values from the tsconfig.node.json include array. Once the app tsconfig had taken over everything had started working again. The problematic include I had was components.d.ts from unplugin-vue-components. This was likely included as an accident for the node tsconfig. Perhaps it may be worth viewing which tsconfig is being loaded in the given context.
Once I had removed the problematic include element, it started using tsconfig.app.json again. Once that tsconfig took over, my problems had ceased.
Things I had done:
Updated
package.json
- "type-check": "vue-tsc --build --force",
+ "type-check": "vue-tsc --noEmit",

- "vue-tsc": "^1.8.27"
+ "vue-tsc": "^2.0.5"

tsconfig.app.json
+ "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo",

tsconfig.node.json
+ "noEmit": true,
+ "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo",
+ "module": "ESNext",
+ "moduleResolution": "Bundler",
- include: ["components.d.*"] // Not the entire include, just that value

tsconfig.vitest.json -- not that it matters much in this context
- "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.vitest.tsbuildinfo",

Note: most of my dependencies are at their latest version, "@vue/tsconfig": "~0.5.1", "typescript": "^5.3.3", "vite": "^5.0.12", etc etc

It seems normal to me. What does the error look like in your screen? Sharing your system info (use the Help: About command) and extension list (Execute Help: Report Issue... >> Click "show" at Include my enabled extensions) may help reproduce the problem.

Yes, like I said in the original issue, unfortunately the errors don't occur in my attempt at a repro. Our issue seems to be fixed in 2.0.6, though!
In case the information is still useful, here is an example of the error in our real repo:

System info:
CPUs | Apple M1 Pro (8 x 24)
-- | --
GPU Status | 2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled
Load (avg) | 1, 11, 11
Memory (System) | 16.00GB (0.24GB free)
Process Argv |
Screen Reader | no
VM | 0%

Remote | SSH: [redacted hostname]
-- | --
OS | Linux x64 4.19.0-26-amd64
CPUs | Intel(R) Xeon(R) E-2224 CPU @ 3.40GHz (4 x 4200)
Memory (System) | 62.76GB (36.70GB free)
VM | 0%

Extensions:
Extension | Author (truncated) | Version
-- | -- | --
auto-close-tag | for | 0.5.15
auto-rename-tag | for | 0.1.10
remotehub | Git | 0.62.0
stylelint-disable-snippets | hed | 1.0.3
mysql-syntax | jak | 1.3.1
vscode-peacock | joh | 4.2.2
latte | Kas | 0.18.0
dotenv | mik | 1.0.1
remote-ssh | ms- | 0.109.0
remote-ssh-edit | ms- | 0.86.0
azure-repos | ms- | 0.38.0
remote-explorer | ms- | 0.4.3
remote-repositories | ms- | 0.40.0
twig-language | Old | 0.10.2
pdf | tom | 1.2.2
twig | wha | 1.0.2
codesnap | adp | 1.3.4
vs-phpcompanion | bla | 2.2.0
vscode-intelephense-client | bme | 1.10.2
npm-intellisense | chr | 1.4.5
php-namespace-resolver | ctf | 0.5.3
vscode-eslint | dba | 2.4.4
index-generator | dec | 2.1.0
gitlens | eam | 14.9.0
vscode-html-css | ecm | 2.0.9
EditorConfig | Edi | 0.16.4
prettier-vscode | esb | 10.1.0
copilot | Git | 1.172.0
copilot-chat | Git | 0.13.0
gitlab-workflow | Git | 4.7.0
todo-tree | Gru | 0.0.226
vscode-graphviz | joa | 0.0.9
i18n-ally | lok | 2.12.0
string-manipulation | mar | 0.5.7
phpstorm-parameter-hints-in-vscode | MrC | 1.2.0
vsliveshare | ms- | 1.0.5918
gremlins | nho | 0.26.0
indent-rainbow | ode | 8.3.1
vscode-yaml | red | 1.14.0
px-to-rem | sai | 1.3.1
phpcs | she | 1.0.8
addDocComments | ste | 0.0.8
code-spell-checker | str | 3.0.1
code-spell-checker-danish | str | 2.2.1
vscode-stylelint | sty | 1.3.0
php-imports | tar | 0.6.0
copy-paste-git-branch | tnr | 0.0.3
lorem-ipsum | Tyr | 1.3.1
volar | Vue | 2.0.5
php-debug | xde | 1.34.0
php-pack | xde | 1.0.3
html-css-class-completion | Zig | 1.20.0

versions after 2.0.6 are bugged again for us though


added scroll to top button in Announcement template

I have fixed issue #472 . Actually I was working on it from some time.
And here goes the screenshot :)

Added scroll to top button in blog template too.

all other templates have that scroll to top button already.

@anushbhatia  @smaranjitghose please review it and merge it.


proto: fixing a few more warnings

cc @phlax these showed up when I ran one of the check_format scripts - I wonder if we could make it fail

i think we should, altho i havent figured out a way to do it yet - i think buf might provide buf linting so i was going to look at that
iiuc, altho  warnings are being issued somewhere i think bazel sees them as info messages which makes it harder to catch

re above when we figure it out i think we also want to add in xds repo


C++ Syntax Misunderstands wchar_t Character Literals

When defining a wchar_t character literal (for example L'#') HLJS 9.5.0 gets stuck incorrectly highlighting the following lines as part of a string. Observe the following C++ program.
#include<stdio.h>
void main() {
    char x = 'x';
    printf(L"#");
    printf(L'#');
    printf("Hello, world");
}

The second ' in L'#' starts a string that consumes the remainder of the file. HLJS does not have this problem with the wchar_t string form (for example L"#").

If you have a PR to resolve this that'd be great.

@egor-rogov I could probably make a PR for this one, but I'm confused at the single quote syntax... which is shared with dts and elm.js:
Ref:
https://github.com/highlightjs/highlight.js/blob/master/src/languages/cpp.js#L25
    variants: [
      ...
      {
        begin: '\'\\\\?.', end: '\'',
        illegal: '.'
      }

I don't understand what illegal: '.' is doing or what its goal is.  Isn't "." going to match anything?  Why do we need an illegal match here at all?  So without understanding it I'm afraid to make a PR.  I did follow the Blame history back as far as I could hoping for a clue but didn't find anything promising.

@yyyc514 Honestly I have no idea. I guess it reflects the fact that in C/C++ character literal can usually be 'a' (character itself) or '\n' (escape sequence) or '\0' (ascii code), but looks it can be done other way.
I wouldn't be afraid, just add enough tests for single-quote literals.

guess it reflects the fact that in C/C++ character literal can usually be 'a' (character itself) or '\n' (escape sequence) or '\0' (ascii code),

Right, but that would be dealt with by BACKSLASH_ESCAPE (I presume)... this only matches a single \ at the very beginning of the string.  I'll play around with it and see if doing it a more obvious ways breaks anything.

I wouldn't be afraid, just add enough tests for single-quote literals.

In there a place in the test system for more singular tests about specific features like this?  I've mostly just played with the auto-detection tests so far.

@wyattallen Do single quotes support all the same fancy things that double quotes do?  Do you have a quick link or information on the differences so i can make sure I do this as well as possible if I'm going to fix?
See above for our current "rules" for this in C++... evidently literal new lines are invalid inside double quoted strings... is that also true for single quoted?

In there a place in the test system for more singular tests about specific features like this? I've mostly just played with the auto-detection tests so far.

Sure. test/markup/cpp/string-literals.txt has some tests already.

My pass at this one:
https://github.com/highlightjs/highlight.js/pull/2156
Just replaces that insanity with a matching matcher for single quoted strings.  It does pass all the tests and should be improved in that previously I don't see how it would have properly detected the "end" (had it been escaped).

This is merged now!