Single file hext.js, modularize

I would like to make the following breaking changes.
@brandonrobertz Let me know if you have any objections.

build a single file: hext.js (-s SINGLE_FILE=1).
build a loadable module (-s MODULARIZE=1, -s EXPORT_NAME="loadHext")

// Use hext.js in node
var loadHext = require('./hext.js');
loadHext().then(hext => {
  const rule = new hext.Rule('');
  const html = new hext.Html('');
  console.log(rule.extract(html));
});

rename repo to html-extract/hext.js
update readme

Yeah this all looks good to me! My only real wish is that we can continue to use this repo as a CDN (meaning we have the compiled hext.js checked in as well as having the release assets available). Everything else can change IMO. The current Module use via vanilla emscripten is pretty clunky.

(The build will produce a single file, called "hext.js". There will not be a "hext.wasm" or "hext.html" - Let me know if you think we should also publish the ".wasm" or ".html")

My only real wish is that we can continue to use this repo as a CDN (meaning we have the compiled hext.js checked in as well as having the release assets available)

I think this would be nice:

.github/workflows/build.yml: Add step that automatically commits the hext.js to the repository on every push, as "dist/hext.js" (using stefanzweifel/git-auto-commit-action or EndBug/add-and-commit). I am using the "dist" subdirectory here, because many JavaScript projects seem to do this by convention.
The release.yml workflow can remain unchanged. When a tag is created, the dist/hext.js is already up to date. We can remove the build step and just add the "dist/hext.js" as a release asset. Caveat: If we push a tag before the workflow run of a prior commit has completed, the "dist/hext.js" is possibly out of date. But I don't think that's going to happen.

The CDN url will look like this<EMAIL_ADDRESS>I will implement this in a fork and see how it goes.

The current Module use via vanilla emscripten is pretty clunky

Very clunky indeed :)
Using a promise to load hext is an improvement, but ideally, hext.Rule and hext.Html would just magically appear in the global scope before the DOM ready event. But I couldn't get that to work, because the wasm is parsed/loaded asynchronously.

It works well in my fork: https://github.com/thomastrapp/hext-emscripten
The CDN url<EMAIL_ADDRESS>Browser tests: https://hext.thomastrapp.com/hext.js-test/  (all OK in Firefox and Android Browser)
I will make the following changes:

new hext release v1.0.2 (https://github.com/html-extract/hext/compare/v1.0.1...c9be568)
push my changes to hext-emscripten
rename repo to html-extract/hext.js
update hext.js to use new hext release
update hext.js readme
new hext.js release
add documentation for hext.js here: https://hext.thomastrapp.com/download

Awesome! Yes as soon as I checked hext-emscripten.js/wasm back into the repo I thought I should have done it via a GH action so I'm glad you did that. And putting it in dist/ makes the most sense. Green light from me to do all the listed changes. ✅

I had another stab at loading hext.js without needing to resolve a promise.
I am documenting this here for future benefit.
There's a relatively new feature: top-level await in modules.
The proposal for top-level await specifically mentions its usefulness to modules using WebAssembly.
Replace the export code in hext.js (last ~6 lines of code) with the following:
const hextInternal = await loadHext(); // works only in ES6 modules
const hext = {
  Rule: hextInternal.Rule,
  Html: hextInternal.Html,
};
export { hext as default, hext, loadHext };

And then you can use it like this:

I am pretty sure that there is another way. A possible avenue is using webpack and the wasm output from emscripten.

Yeah so if you want to go the module route, which I think it smart, we could boil it down to this if we exported Rule and Html (right now loadHext is the only export AFAICT):
import { Rule, Html } from<EMAIL_ADDRESS>
This would be by far the simplest way to accomplish the loading. But of course it will make it so old browsers can't work with it. I don't think that should restrain us, though. We're pretty much the only hext.js users right now and we should be looking forward. $0.02.

All right so I've done a bit of poking around and almost got to the above.
If we use the -s EXPORT_ES6=1 flag in our Makefile then we can load hext with a single script (two lines of JS using one await):

In order to get to the single line import {Rule, Html} from '/hext.js' import, we'll need to mess with the pre/post-js args to the closure compiler. I can keep going down this path, but wanted to hear your thoughts.

Okay, so I went down the rabbit hole and got a fully loaded hext.js module that lets us do this in the browser:

I created a new branch with this work: hext.js The next thing I want to look at is reducing the size of the JS/WASM bundle.
Let me know what you think and thanks for getting this kicked off!

Just to clarify, I wished I could use hext.js like this:
 // no module

And I don't want to force users to use modules.
But I haven't found a solution yet. So I have to be content with loadHext for now (It is also not that important, but I love to brood over details like this).
How about this:

dist/hext.js -> non-module, with loadHext
dist/hext.mjs -> module, without loadHext (like in your branch)

Is that a good solution?
I am currently improving the documentation at https://hext.thomastrapp.com/download whenever I find the time.
Let me know if you want to release this as soon as possible. I will then prioritize the new release.
Off-topic: I really like your example
//

Hello

World

//

const result = rule.extract(html).map(x => x.my_text).join(", ");
console.log(result); // "Hello, World"

That's beautiful.

Just to clarify, I wished I could use hext.js like this:
 // no module

Makes sense. Using WASM is going to prevent that as the API is async. One option (not sure if this can work) would be to use emscripten's non-WASM build (pure JS) but I think we would need to heavily modify the loader JS.

How about this:

dist/hext.js -> non-module, with loadHext
dist/hext.mjs -> module, without loadHext (like in your branch)

Is that a good solution?

Perfect solution. I didn't realize node.js hated the ES6 module, so it's best to keep it in the .mjs file.

Off-topic: I really like your example
//

Hello

World

//

const result = rule.extract(html).map(x => x.my_text).join(", ");
console.log(result); // "Hello, World"

That's beautiful.

😂 Thanks

https://cdn.jsdelivr.net/gh/html-extract/hext.js/dist/hext.js
https://cdn.jsdelivr.net/gh/html-extract/hext.js/dist/hext.mjs
All done - Thanks!


nexus: Expose docker registry

Expose TCP port for Nexus Docker Registry at 9123/tcp

LGTM, merging


Add built-in layout components

Layout components can be used to change the look of a single slide, similar to templates in other presentation apps. Some built-in layouts could work with the current theme to invert colors and make other small style adjustments.
Example:
export { yellow as theme } from 'mdx-deck/themes'

# Normal Slide

---
export { Invert as default } from 'mdx-deck/layouts'

# Slide with Layout

Maybe seperate repos?  Just don't want too much code bloat for layouts that aren't used everytime.


hydration crash with npm "Cannot read properties of null (reading 'nextSibling')"

Describe the bug
SolidJS hydration seems to behave differently with npm and pnpm, leading to a crash with npm but not with pnpm.
The bug was originally filed at https://github.com/chakra-ui/zag/issues/385. Any Zag component crashes during hydration but not when client-side rendered only via render(). Efforts to reproduce the issue yielded that running the repro with npm crashes while pnpm does not.
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nextSibling')
    at index.page.tsx:14:3
    at Checkbox (index.page.tsx:20:34)
    at @solid-refresh:10:42
    at untrack (chunk-CGI4PW6R.js?v=14626c3e:447:12)
    at Object.fn (@solid-refresh:10:28)
    at runComputation (chunk-CGI4PW6R.js?v=14626c3e:751:22)
    at updateComputation (chunk-CGI4PW6R.js?v=14626c3e:734:3)
    at createMemo (chunk-CGI4PW6R.js?v=14626c3e:253:5)
    at hmrCompWrapper (@solid-refresh:7:20)
    at chunk-CGI4PW6R.js?v=14626c3e:555:1

Your Example Website or App
https://stackblitz.com/edit/solidjs-templates-chv1jk?file=src/pages/index.page.tsx
Steps to Reproduce the Bug or Issue
with npm:

Open the stackblitz link.
Open the console (inspect)
npm i
npm run dev
crash will appear in the console

with pnpm:

Open the stackblitz link.
Open the console (inspect)
pnpm i
pnpm run dev
works fine

Expected behavior
No client-side crash during hydration when run with npm (or any other package manager).
Screenshots or Videos

Platform

OS: macOS
Browser: Chrome
Version: 107
SolidJS: 1.6

Additional context
You can download the project from Stackblitz. Running npm i and pnpm i locally seems to resolve the same SolidJS version.

From my investigation it looks like It's related with nested elements with spread props overriding children. It works if the children prop is used instead of the JSX form. It worked until 1.6. I encountered the same problem, more info in linked issue :)

Thanks for reporting. The last release(1.5) was all about improving server-side Spreads, and this release(1.6) about the client. I would guess a change in the client logic is causing the slight mismatch.

@pawelblaszczyk5 The problem in this issue existed with v1.5 too. Might be unrelated to the other issue you filed.
@ryansolid But why would npm crash and pnpm not?

@pawelblaszczyk5 The problem in this issue existed with v1.5 too. Might be unrelated to the other issue you filed.

Oh, yeah, you're right, I must have checked something incorrectly yesterday. It's not working on v1.5 also, it's the same issue. I also discovered it while trying to use zag 😄

Yeah it's a compiler bug. I found it and should get it out today.

@ryansolid the bug has not been solved. The repro yields the same error with v1.6.2.
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nextSibling')

Make sure that the babel plugin has updated. babel-preset-solid 1.6.2 will ensure it. I updated the stackblitz template and I think it is working: https://stackblitz.com/edit/solidjs-templates-r53rfw?file=src/pages/index.page.tsx

I can confirm. Works. It seems like NPM has problems resolving babel-preset-solid though which might explain the difference between NPM and PNPM.
If other people run into the issue, I manually added babel-preset-solid to the package JSON. See this commit.


Update sbt-ci-release to 1.5.0

Updates com.geirsson:sbt-ci-release from 1.4.31 to 1.5.0.
Release Notes/Changelog
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.geirsson", artifactId = "sbt-ci-release" } ]

labels: sbt-plugin-update, semver-minor

Hmm.

No issue building locally so there's something fishy happening with CI.

Sporadic. Confidence high!


[Bug]: Hardlink errors with PowerToys 0.72

Prerequisites

[X] I have written a descriptive issue title.
[X] I have searched all issues/PRs to ensure it has not already been reported or fixed.
[X] I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name
powertoys
Expected/Current Behaviour
PowerToys can be upgraded without errors.
Steps to Reproduce
PS> scoop update powertoys
Running post_install script...
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
   3 |      Get-ChildItem -Path "$dir\dll\WinAppSDK" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\WinAppSDK' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.
Get-ChildItem:
Line |
  11 |      Get-ChildItem -Path "$dir\dll\Interop" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\Interop' because it does not exist.
Get-ChildItem:
Line |
  14 |      Get-ChildItem -Path "$dir\dll\dotnet" | ForEach-Object {
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\scoop\apps\powertoys\current\dll\dotnet' because it does not exist.

Possible Solution
PowerToys 0.72 significantly changed the package structure:

Greatly reduced the PowerToys installed space by having utilities share the same installed path. When compared to 0.71, the 0.72 x64 machine installed version of PowerToys reduces the size reported in the Installed Apps screen from 1.15GB to 785 MB and the size in File Explorer properties for the installation folder from 3.10GB to 554 MB.

Thus the post_install script throws errors as it cannot find the paths listed in the recipe.
However, in my testing everything seems to be fine even without hardlinks.
Scoop and Buckets Version
Current Scoop version:
v0.3.1 - Released at 2022-11-15

'Extras' bucket:
bae852f02 (HEAD -> master, origin/master, origin/HEAD<EMAIL_ADDRESS>Fix hash (Closes #11687)

'Main' bucket:
2805b25c5 (HEAD -> master, origin/master, origin/HEAD<EMAIL_ADDRESS>Set $env:SPICETIFY_CONFIG to $persist_dir

'r-bucket' bucket:
d59fa5f8 (HEAD -> master, origin/master, origin/HEAD) r-devel: Update to version r84819

'scoops' bucket:
36ece38 (HEAD -> master, origin/master, origin/HEAD) nirlauncher: Update to version 1.30.4

Scoop Config
alias last_update          scoop_branch scoop_repo
----- -----------          ------------ ----------
      2023.08.02. 10:16:30 master       https://github.com/lukesampson/scoop

PowerShell Version
Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Additional Softwares
None

Highlights
Greatly reduced the PowerToys installed space by having utilities share the same installed path. When compared to 0.71, the 0.72 x64 machine installed version of PowerToys reduces the size reported in the Installed Apps screen from 1.15GB to 785 MB and the size in File Explorer properties for the installation folder from 3.10GB to 554 MB.
SOURCE: https://github.com/microsoft/PowerToys/releases/tag/v0.72.0

I removed the install script that creates the hard links and tested a couple of features in the sandbox. please report again if its tools doesn't work.


Custom handler isn't build

When you add a custom handler like this :
const compat = require("serverless-nextjs-plugin/aws-lambda-compat");
const Raven = require("raven");
const RavenLambdaWrapper = require("serverless-sentry-lib")

module.exports = page => {
    return RavenLambdaWrapper.handler(Raven, (event, context, callback) => {
        compat(page)(event, context, callback);
    })
};

After build phase, the handler isnt transform as pages are. I think this should be the custom behavior.
Alternative : add the custom packages in the final artifact, but I think first option is the best.

Hi @romainquellec, not sure what do you mean by transformed?  The custom handler is included in the deployment zip artifact.

I think I understand what he means, that raven and serverless-sentry-lib aren't added to the bundle automatically.
You need to ensure that raven and serverless-sentry-lib packages and their dependencies are included in your package by adding them to your (not) exclude.
My config looks like this:
package:
  excludeDevDependencies: false
  exclude:
    - './**'
    - '!node_modules/**'

Note that I'm using a monorepo and most packages are hoisted to the root. Only the packages I want to include are not hoisted. It's a nifty way not having to specify every single package manually.

@mekwall Exactly that. :D

Another solution is to create a sub-package inside your package, that only has raven and serverless-sentry-lib in its package.json and then add the node_modules directory from that package to your (not) exclude.

@romainquellec Did any of the solutions above worked for you? Including the node_modules you need as @mekwall suggested sounds sensible.
Automatically including dependencies of the custom handler I think goes beyond the scope of the plugin.

I didnt try.
Imo, The handle should be treated as pages are. There are no reason the handle shouldnt be optimized  with webpack.
(Also, sometimes, when you include a package with serverless (as @mekwall suggested), the other packages needed for the included package arent automatically included)

@romainquellec If you create a sub-package, with its own package.json you just run npm install in the sub-package and then include the node_modules from the sub-package in your serverless config. That way you get all of the dependencies you need.
And I kind of agree with @danielcondemarin that this might be out of scope for this plugin to bundle all of it. Maybe if there's a way to hook into Next.js build process in some way, but having two different build processes feels wrong.

Closing as there are possible workarounds for this and building the handlers should be done outside the plugin


Relax version requirement for Roar

@yogeshjain999 can you also add a tag and push to rubygems, please? :)

@jandudulski done, thanks for pushing this through 🍻

@jandudulski are you interested in updating Appraisals for rails versions and replacing travis-ci with GH actions in this repo ?  No pressure!

@yogeshjain999 I'll put it on my list ;)


feat: allow access to the toast config in custom Toast view

Allow get access to the toast config in custom Toast view

is there a specific use case where you need the config?

I was trying to replicate the AppleToastView behavior using the config like this :
switch toast.config.direction {
case .bottom:
        bottomAnchor.constraint(equalTo: superview.layoutMarginsGuide.bottomAnchor, constant: 0).isActive = true
case .top:
        topAnchor.constraint(equalTo: superview.layoutMarginsGuide.topAnchor, constant: 0).isActive = true
case .center:
        centerYAnchor.constraint(equalTo: superview.layoutMarginsGuide.centerYAnchor, constant: 0).isActive = true
}


lefthook: 1.6.1 -> 1.6.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/lefthook/versions.
meta.description for lefthook is: Fast and powerful Git hooks manager for any type of projects
meta.homepage for lefthook is: https://github.com/evilmartians/lefthook
meta.changelog for lefthook is: https://github.com/evilmartians/lefthook/raw/v1.6.2/CHANGELOG.md
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.6.2 with grep in /nix/store/d2z5hh7kpblvmmxhynmgn5i17dwk4d16-lefthook-1.6.2
found 1.6.2 in filename of file in /nix/store/d2z5hh7kpblvmmxhynmgn5i17dwk4d16-lefthook-1.6.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
lefthook

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/d2z5hh7kpblvmmxhynmgn5i17dwk4d16-lefthook-1.6.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A lefthook https://github.com/r-ryantm/nixpkgs/archive/5b6d5069ce925049e742f8ac42dd068d6a75c056.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/5b6d5069ce925049e742f8ac42dd068d6a75c056#lefthook

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/d2z5hh7kpblvmmxhynmgn5i17dwk4d16-lefthook-1.6.2
ls -la /nix/store/d2z5hh7kpblvmmxhynmgn5i17dwk4d16-lefthook-1.6.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

lefthook

Maintainer pings
cc @AndersonTorres for testing.

@NixOS/nixpkgs-merge-bot merge


[New game]: Cover Up game

🎮 Game Request
Game logic and basic description :
A user would need to cover the given object with the available resources, once area covered becomes 100% the games end. Will be using HTML,CSS,JS
Point down the features
Game points:  Would help the user to learn the concept of outer surface area. Also they will learn how to use resources optimally.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @Vraj1103 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hello @Vraj1103, Time's Uppp!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗

Hey @Vraj1103 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Add Fill Patterns to Barchart Bars

Currently, bars can be customized with a series styling options; however, it is not possible to add image patterns to the bars, or the areas under line charts.
This would be a great addition to such an awesome framework, and would be extremely helpful for visually impaired people.
Resources:
This website contains several different patterns: https://bocoup.com/weblog/using-svg-patterns-as-fills/
An example of this done in SVG can be seen in this jfiddle : http://jsfiddle.net/yduKG/155/

Have you tryed using css class?

I did some research on the subject, and patterns can be manipulated with SVG, not CSS. I ended up extending c3 with the code below:
c3.chart.internal.fn.afterInit = function () {
// can do something
d3.select('defs')
.append('pattern')
.attr('id', 'diagonal-stripe-1')
.attr('patternUnits', 'userSpaceOnUse')
.attr('width', 10)
.attr('height', 10)
.append('image')
.attr('xlink:href', 'data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScxMCcgaGVpZ2h0PScxMCc+CiAgPHJlY3Qgd2lkdGg9JzEwJyBoZWlnaHQ9JzEwJyBmaWxsPSd3aGl0ZScvPgogIDxwYXRoIGQ9J00tMSwxIGwyLC0yCiAgICAgICAgICAgTTAsMTAgbDEwLC0xMAogICAgICAgICAgIE05LDExIGwyLC0yJyBzdHJva2U9J2JsYWNrJyBzdHJva2Utd2lkdGg9JzEnLz4KPC9zdmc+Cg==')
.attr('x', 0)
.attr('y', 0)
.attr('width', 10)
.attr('height', 10);
};
After adding the function above, I can use "url(#diagonal-stripe-1)" as a color. This works kind of nice with bar charts, but doesn't work as well with line area charts. This is due to the internal code of c3 which grabs the fill color, and changes its opacity to fill the area, and then it uses that same color to paint the line above the area with a different opacity.

Very nice! Thank you!

@sitandrelax Would you mind submitting that as a PR? Would be super cool to have in core!

I guess I can work on something. Not sure if there will be mass appeal for this feature.

Please share a js fiddle for the same.
Thanks in advance

I see in this link that they use css classes for pattern. I dont see why thoses classes  could ne be used with C3
http://iros.github.io/patternfills/sample_css.html

can we add fill patterns in pie chart using c3.js?


Remove unused fields from /private/target/ endpoint

The following fields are used by the front-end:
approved_name
approved_symbol
biotype
cancerbiomarkers
chemicalprobes
chromosome
dbxrefs
drugs
ensembl_description
ensembl_external_name
ensembl_gene_id
gene_end
gene_start
go
hallmarks
id
mouse_phenotypes
name_synonyms
ortholog
pdb
previous_symbols
reactome
status
strand
symbol_synonyms
uniprot_accessions
uniprot_function
uniprot_keywords
uniprot_id
uniprot_subcellular_location
uniprot_subunit

The following fields are not and could therefore be removed entirely from the REST API to reduce bloat. Many take the value null, [] or {} seemingly all the time. They may be useful within the back-end codebase, but could be removed from the API at least.
alias_name
alias_symbol
ccds_ids
chembl
cytobands
data_release
drugbank
ensembl_assembly_name
ensembl_gene_version
ensembl_release
entrez_gene_id
enzyme_ids
gene_family_description
gene_family_tag
hgnc_id
interpro
is_active_in_ensembl
is_ensembl_reference
is_in_swissprot
locus_group
pfam
previous_names
protein_classification
pubmed_ids
refseq_ids
uniprot_mapping_date
uniprot_pathway
uniprot_similarity
vega_ids

I'm all in favour of reducing the size of the REST API response from the /private/target/<geneId> endpoint.
One suggestion I have is that the endpoint could only serve summary statistics that we need for a dashboard view. That would ensure that the dashboard loads quickly and isn't slowed down by unnecessary data. When a user clicks a widget and is taken to a detail view, we could run another request to a new (?) endpoint that takes the geneId and widgetId and returns only the relevant data. For example, if a user clicks the drugs widget on the BRAF dashboard, we could run a call to an endpoint like /private/target/ENSG00000157764&data=drugsWidget.
This isn't all that different from the current architecture as for many of the accordion tabs, we run another call already. Instead, the change would be to the endpoint that would only return the relevant data in an effort to improve the Platform's speed and responsiveness.
But maybe instead of building another endpoint, this is something we could implement with a GraphQL interface server in front of the current API?

@andrewhercules bear in mind that not all the information that is displayed in the target profile page is stored in the ot backend and served by the api.
Specifically, information for the gene tree, protein structure, gtex expression data, protein interactions, etc are external

@mkarmona looking at this to start implementation of the graphQL schema


When making a request, how can I see the request URL?

I'm making a request in Moya, I'd like to see the request URL, is this possible?

Do you mean logging it to the console? If so, checkout NetworkLoggingPlugin.

@scottrhoyt If you don't mind, how would I use NetworkLoggingPlugin to do what I need to do?

Sure, you just initialize a NetworkLoggingPlugin and pass it to the plugins parameter of your MoyaProvider initializer. (e.g. plugins: [NetworkLoggingPlugin()]).

How would I get the request URL? @scottrhoyt

@dannymout in Xcode console log

@scottrhoyt @gperdomor Perfect. Didn't know that is how it worked, thanks.


use of closed network connection

DomainGetXMLDesc: write unix @->/var/run/libvirt/libvirt-sock: use of closed network connection.
code:
xmlDesc, err := l.DomainGetXMLDesc(*domain, 0)
if err != nil {
log.Printf("failed to DomainGetXMLDesc: %v", err)
return err
}

libvirt service is running normally.

can you provide full example? i don't see such error


Fix old or incorrect contents in the doc build instruction

Type of change

Documentation update

Description
This patch fixes old or incorrect contents in the doc build instruction.
Additional details
Related issues
Release Note

@satota2 Which branches should this be backported to?

@nikhil550 This seems to need to be backported to the release-2.3 branch.
The release-2.2 branch seems to still use the older build process that this patch doesn't cover.

@mergifyio backport release-2.3


just can't give any information "undefined"

Check the error and data.
Seems like have some error on it.

whole the variables looks like 'undefined'
console.log(' Result: ' + res + ' data: ' + data + ' res: ' + res);
// Result: undefined data: undefined res: undefined

console.log(' err: ' + err + ' data: ' + data + ' res: ' + res);
// err: Error: getaddrinfo ENOTFOUND wordpress.localhost wordpress.localhost:80 data: undefined res: undefined

which dependency have this problem?

@ayzakh So there the error you must correct in your environment:

Error: getaddrinfo ENOTFOUND wordpress.localhost wordpress.localhost:80

I solved this problem. The problem was in /etc/hosts file. Thanks.

;)


Port from crossbeam-channel to flume

This is a prerequisite for message priorities #22 - crossbeam has built-in
randomization when receiving messages, while flume lets us control that
using a feature flag.
flume's API is largely the same as crossbeam's, only real difference is
that select() is constructed using builder pattern rather than a macro.
Actor own benchmark result change (crossbeam -> flume):
circular/circular (2 actors)
                        time:   [3.0926 ms 3.1223 ms 3.1528 ms]
                        thrpt:  [317.18 Kelem/s 320.28 Kelem/s 323.35 Kelem/s]
                 change:
                        time:   [-24.762% -21.495% -17.992%] (p = 0.00 < 0.05)
                        thrpt:  [+21.940% +27.380% +32.912%]
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) high mild
  2 (2.00%) high severe
circular/circular (native CPU count - 1)
                        time:   [3.9945 ms 4.0224 ms 4.0493 ms]
                        thrpt:  [246.96 Kelem/s 248.61 Kelem/s 250.34 Kelem/s]
                 change:
                        time:   [-7.5891% -5.5178% -3.4030%] (p = 0.00 < 0.05)
                        thrpt:  [+3.5229% +5.8400% +8.2123%]
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  1 (1.00%) low severe
  6 (6.00%) low mild
  3 (3.00%) high mild
circular/circular (native CPU count)
                        time:   [20.821 ms 21.743 ms 22.666 ms]
                        thrpt:  [44.119 Kelem/s 45.993 Kelem/s 48.027 Kelem/s]
                 change:
                        time:   [-16.421% -10.076% -3.3897%] (p = 0.00 < 0.05)
                        thrpt:  [+3.5087% +11.205% +19.648%]
                        Performance has improved.
circular/circular (50 actors)
                        time:   [25.593 ms 27.095 ms 28.638 ms]
                        thrpt:  [34.918 Kelem/s 36.907 Kelem/s 39.073 Kelem/s]
                 change:
                        time:   [-31.525% -24.649% -17.014%] (p = 0.00 < 0.05)
                        thrpt:  [+20.502% +32.712% +46.038%]
                        Performance has improved.

That looks good! Measured on my laptop with frequency scaling and thermal
throttling, so there may be some noise.

Sorry I didn't review this earlier. Those performance numbers look great, and the replacement implementation seems pretty straightforward to me. Post-merge LGTM!

Sorry I didn't review this earlier. Those performance numbers look great, and the replacement implementation seems pretty straightforward to me. Post-merge LGTM!

Thanks for post-merge review! :bow:

Same as Brian! Looks great, and yay for easy performance gainzzz.


open source license?

this looks like a useful starting point to generate a fun game to add to my website, would you mind adding an open source license so that I know its OK to reuse & change the code? Thanks.

There you go it should have one now :)

Fantastic, thanks.


A Cop to detect wasteful initializations

Is your feature request related to a problem? Please describe.
I frequently encounter non-memoized method definitions that involve generation of a constant object that doesn't depend on the state of the Class / Module.
Example
Given that there's a class with following instance methods:
def fallback_data(config)
  {
    :foo => "bar",
    :sit => "amet",
  }.merge(config)
end

def cross_over(type)
  return unless %w[lorem ipsum dolor sit amet alpha].include?(type)

  # proceed doing stuff
end

The Hash generated in :fallback_data and the intermediate array in :cross_over are both going to remain the same in any given instance of the Class. Multiple calls to these methods are going to allocate those objects unnecessarily .
Describe the solution you'd like
Flag such methods and recommend stashing the constant-value objects as "constants", or consider memoizing them as "singleton methods"

Hi, @ashmaroli!
The performance cops have recently been moved to their own repository. Please help move your issue over there. Thank you! 🙇

@Drenmi Will you be able to transfer this issue using the GitHub UI?
https://help.github.com/en/articles/transferring-an-issue-to-another-repository


Opaque errors when token verification fails

Problem Statement
Caveat: I am new to both Guardian and Elixir
While trying to get the decode_and_verify function working, I was thwarted by obscure error messages. In the end my problem was fixed by being explicit about the allowed algorithms, but the error returned by this function was always CaseClauseError{term: {:error, :badarg}}}
I think this is because the root error is returned by decode_token, then returning_tuple maps it to { :error, _ } (already striping out any useful info), and then the calling function has no matching case clause anyway so it throws a generic CaseClauseError.
This exception is caught in decode_and_verify and an error message is returned, but there is no chance of debugging where the failure originally occured.
I'm not sure what the right behaviour should be in this case or what is canonical Elixir, but as it stands I ended up having to reproduce the call chain line-by-line in my client code until I found the problem, which isn't ideal.
Solution Brainstorm
No response

Hello, @rawnsley!
Perhaps a log message would be helpful? At least it would make it easier to debug the problem

@f-francine thank you so much for the help.

@rawnsley do you mind filling up the "Solution Brainstorm" I am not sure what you are asking us to do or what you would propose.
Or even much better, since you already know how to replicate the issue and whatnot, create a PR with the proposed solution. I am here to help you with it as much as I can.


[ARM][Topi] Improving Int8 Perf in Spatial Conv2D schedule.

I am working on improving the performance of Int8 conv on Raspberry Pi 3.
For Conv2D, there is an upcast from int8 to int32 before performing the dot-product. ARM ISA has an instruction called vmlal.s16 that takes 3  SIMD registers each containing 4 16-bit values and does FMA producing 1  SIMD register containing 4 32-bit values. However, LLVM (4.0, 6.0 and 8.0) is not able to efficiently use this instruction. In the absence of this PR, assembly looks something like this
	add	r2, sp, #304
	vmlal.s16	q12, d0, d4
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #208
	vmlal.s16	q12, d10, d0
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #192
	vmlal.s16	q12, d8, d0
	vld1.64	{d0, d1}, [r2:128]
	sub	r2, r6, #7
	mov	r6, r7
	vmlal.s16	q12, d0, d14
	vld1.8	{d0[]}, [r2]
	add	r2, sp, #192
	vmovl.s8	q4, d0
	vst1.64	{d8, d9}, [r2:128]
	add	r2, sp, #240
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #176
	vmlal.s16	q14, d8, d0
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #128
	vmlal.s16	q14, d0, d12
	vld1.64	{d12, d13}, [r2:128]
	add	r2, sp, #288
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #96
	vmlal.s16	q14, d12, d0
	vld1.64	{d8, d9}, [r2:128]
	add	r2, sp, #352
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #224
	vmlal.s16	q14, d8, d0
	vld1.64	{d14, d15}, [r2:128]
	add	r2, sp, #80
	vmlal.s16	q14, d14, d2
	vld1.64	{d2, d3}, [r2:128]
	add	r2, sp, #304
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #208
	vmlal.s16	q14, d6, d4
	vld1.64	{d4, d5}, [r2:128]
	add	r2, sp, #240
	vmlal.s16	q14, d2, d0
	vmlal.s16	q14, d10, d4
	vld1.64	{d10, d11}, [r2:128]
	add	r2, sp, #192
	vld1.64	{d6, d7}, [r2:128]
	add	r2, sp, #160
	vmlal.s16	q13, d7, d11
	vld1.64	{d10, d11}, [r2:128]
	add	r2, sp, #176
	vld1.64	{d6, d7}, [r2:128]
	add	r2, sp, #288
	vmlal.s16	q13, d7, d11
	vld1.64	{d10, d11}, [r2:128]
	add	r2, sp, #352
	vmlal.s16	q13, d13, d11
	vld1.64	{d10, d11}, [r2:128]
	add	r2, sp, #336
	vld1.64	{d6, d7}, [r2:128]
	add	r2, sp, #144
	vmlal.s16	q13, d9, d11
	vld1.64	{d8, d9}, [r2:128]
	add	r2, sp, #320
	vld1.64	{d10, d11}, [r2:128]
	add	r2, sp, #272
	vmlal.s16	q13, d15, d7
	vmlal.s16	q13, d9, d11
	vmlal.s16	q13, d3, d1
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #256
	vmlal.s16	q13, d1, d5
	vld1.64	{d0, d1}, [r2:128]
	add	r2, sp, #112
	vld1.64	{d2, d3}, [r2:128]
	vmlal.s16	q14, d0, d2
	vmlal.s16	q13, d1, d3
	bne	.LBB6_5

However, if we add an intermediate upcasting to int16 i.e. instead of going from int8 to int32, we can go from int8 to int16 and then this int16 can go to conv2D, it results in much better packing of compute and memory instructions
.LBB7_6:
	add	r2, lr, r8
	add	r1, r12, #32
	vld1.64	{d0, d1}, [r1:128]
	add	r1, r12, #16
	add	r3, r2, #10
	add	r8, r8, #8
	vld1.64	{d4, d5}, [r1:128]
	mov	r1, r2
	vld1.16	{d6[]}, [r1:16], r7
	cmp	r8, #24
	vld1.16	{d7[]}, [r3:16]
	add	r3, r2, #2
	vld1.16	{d10[]}, [r1:16]
	add	r1, r2, #8
	vld1.16	{d2, d3}, [r10:128], r0
	vmlal.s16	q14, d6, d2
	vmlal.s16	q13, d6, d3
	vld1.16	{d6[]}, [r3:16]
	add	r3, r2, #12
	vmlal.s16	q12, d6, d2
	vmlal.s16	q11, d6, d3
	mov	r12, r10
	vmlal.s16	q14, d6, d4
	vld1.16	{d8[]}, [r3:16]
	vmlal.s16	q13, d6, d5
	add	r3, r2, #4
	vld1.16	{d6[]}, [r1:16]
	vmlal.s16	q15, d7, d3
	vmlal.s16	q9, d6, d2
	add	r1, r2, #6
	vmlal.s16	q8, d7, d2
	vld1.16	{d9[]}, [r3:16]
	vmlal.s16	q10, d6, d3
	vmlal.s16	q15, d8, d5
	vld1.16	{d2[]}, [r1:16]
	vmlal.s16	q12, d9, d4
	vmlal.s16	q11, d9, d5
	vmlal.s16	q9, d7, d4
	vmlal.s16	q10, d7, d5
	vmlal.s16	q8, d8, d4
	vmlal.s16	q13, d9, d1
	vmlal.s16	q14, d9, d0
	vmlal.s16	q15, d10, d1
	vmlal.s16	q8, d10, d0
	vmlal.s16	q10, d8, d1
	vmlal.s16	q9, d8, d0
	vmlal.s16	q11, d2, d1
	vmlal.s16	q12, d2, d0

I tested this with one Conv2D and with auto-tuning.

Workload - Input shape - 1, 64, 16, 16, Kernel - 64, 64, 3, 3
Platform - Raspberry Pi - 0.6 GHz
Auto-tuning done for both FP32 and Int8 conv
FP32 Latency = 3817 us, Int8 latency = 3015 us
In the absence of this PR, Int8 latency is worse than FP32.

@jackwish @yzhliu @FrozenGene @merrymercy @zhiics  @u99127

Duplicating the message from the comments here for discussion.
An alternative to this PR can be a legalize pass - which when sees a conv2d with int8 inputs, inserts an upcast to int16. In this case, the upcast will show up at Relay level, and the topi will remain unchanged. I manually verified that LLVM gives good assembly when conv2D inputs are int16.
In both the cases, the memory footprint takes a hit as we upcast weight to int16. For the alternate implementation, they show up in artifacts (or disk). For current PR, the allocation happens internally in the conv operator.

Ha! This is so interesting - it is very similar to our internal try many months ago. I think legalization is a good idea, though it is not easy to read.
And, we are going to share some end to end INT8 benchmarks on TVM Shanghai Meetup next week (presented by @FrozenGene).
Also, from the tuning experience, I recently get the idea of trying trivial im2col schedule (without tensorize). Maybe we can share some code later :).

@jackwish Yes, sharing code will be very helpful. For now, do you prefer changing schedule OR Legalize pass?
Changing Schedule

(+) The change is contained to only one template.
(-) Schedules are generally hard to understand. In general, I try to avoid complicating them.

Legalize Pass

(+) The codebase might be cleaner (if one understands Relay passes).
(+) Topi schedules are generally hard to understand. In general, I try to avoid complicating them. This avoids that.
(-) Applies to all templates. For example, if I write a new template (like direct, winograd), legalize will upcast.

I dont have any strong opinion.

@jackwish I'd be very interested in those results. I got some good results for NHWC on ARMv7 by porting the QNNPACK kernels over
and tensorizing (https://github.com/ajtulloch/tvm/blob/95e5e2d44a08e2dfb8444706370505944ffb7c91/topi/python/topi/arm_cpu/conv2d_int8.py#L9-L166), and it'd be awesome to see how you folks have approached this problem.

@jackwish I'd be very interested in those results. I got some good results for NHWC on ARMv7 by porting the QNNPACK kernels over
and tensorizing (https://github.com/ajtulloch/tvm/blob/95e5e2d44a08e2dfb8444706370505944ffb7c91/topi/python/topi/arm_cpu/conv2d_int8.py#L9-L166), and it'd be awesome to see how you folks have approached this problem.

@ajtulloch Thanks for the interest and great discussion between us ever. :-)
I want to summary some high idea of us and will present the results next TVM meetup in Shanghai.
For Convolution:

We use NHWC layout
Currently, we use Tensorize.

We stuied QNNPACK, but QNNPACK can not be used by us directly, some concept in QNNPACK we can not simulate, for example, indirect buffer. So we write the kernel by ourselves.
For Depthwise Convolution

We use NHWC layout
We don't use Tensorize.

Yes. We use INT6 * INT16 + INT16 -> INT32 instruction (SMLAL), which is better than INT32*INT32 + INT32->INT32. The way we do is we will substract the input_zero_point / kernel_zero_point before computation, at there, we will cast the dtype from UINT8 -> INT16.
For Depthwise convolution, even though we don't use Tensorize, we still get the performance bettern than QNNPACK(in mobilenet V1 / mobilenetV2, only 2 layers slower than it, others we are faster than QNNPACK). Amazing result. I wanna list two keypoints:

Avoid data pack. In im2col / spatial pack, we will do data pack on H / W, which is cost on depthwise convolution, you could compute it directly and just split C. i.e. like this:

    kvshape = (C // VC, M, KH, KW, VC)
    oshape = (N, OH, OW, C)
    dvshape = (N, OH, OW, C // VC, KH, KW, VC)

compute_at is very important in depthwise convoltion. data_pad_inline / data_vec_inline / conv_inline should be tunable, this is one important factor to beyond QNNPACK.

Currently, we have tested MobilenetV2 on rasp, we are 1.34X compared with QNNPACK. In our in-house model, we are beyond more compared with QNNPACK. We will present more in TVM meetup.

@jackwish Yes, sharing code will be very helpful. For now, do you prefer changing schedule OR Legalize pass?
Changing Schedule

(+) The change is contained to only one template.
(-) Schedules are generally hard to understand. In general, I try to avoid complicating them.

Legalize Pass

(+) The codebase might be cleaner (if one understands Relay passes).
(+) Topi schedules are generally hard to understand. In general, I try to avoid complicating them. This avoids that.
(-) Applies to all templates. For example, if I write a new template (like direct, winograd), legalize will upcast.

I dont have any strong opinion.

If someone is schedule guy, modify the schedule frequently, we apply it in schedule is better for them, because they could handle it whole in schedule. However, from the code viewpoint, I suggest adding in Pass. Because this should be applied in all templates. And for ARMv8.2, dot product instruction is better, could be done in legalize too.

@FrozenGene wow, those are very impressive results. Congratulations, looking forward to the talk and the code :)

@jackwish I'd be very interested in those results. I got some good results for NHWC on ARMv7 by porting the QNNPACK kernels over
and tensorizing (https://github.com/ajtulloch/tvm/blob/95e5e2d44a08e2dfb8444706370505944ffb7c91/topi/python/topi/arm_cpu/conv2d_int8.py#L9-L166), and it'd be awesome to see how you folks have approached this problem.

@ajtulloch I looked a bit into your code, very decent design! I have not tried tensorization with spatial pack schedule, would you please share some performance result?

@jackwish Yes, sharing code will be very helpful. For now, do you prefer changing schedule OR Legalize pass?
Changing Schedule

(+) The change is contained to only one template.
(-) Schedules are generally hard to understand. In general, I try to avoid complicating them.

Legalize Pass

(+) The codebase might be cleaner (if one understands Relay passes).
(+) Topi schedules are generally hard to understand. In general, I try to avoid complicating them. This avoids that.
(-) Applies to all templates. For example, if I write a new template (like direct, winograd), legalize will upcast.

I dont have any strong opinion.

Hi @anijain2305 , I think a Legalize Pass may lead to a clean code structure or architecture, while a Changing Schedule contribute to a easy to read. I feel the same on having no strong opinion :(. Yet, one thing that I am considering is that, if the legalization is going to handle all, will it make the tensorize compute pattern matching a bit more hard to write or debug or something. By this I mean, in schedule we write int8 cast to int32 and multiply, legalization rewrites to int8 cast to int16 and multiplied to int32, so what is the compute pattern shall a tensorize to match? Not sure if this will be a problem :)

@jackwish Thanks for the comment.
If we go legalize way, following kind of transformation would happen
Original Relay graph --> conv2d(%int8_data, %int8_kernel)
AfterLegalize Relay graph -->
%int16_data = cast(%int8_data, dtype="int16")
%int16_kernel = cast(%int8_kernel, dtype="int16")
conv2d(%int16_data, %int16_kernel)
So, in this case, even if we want to use tensorize, we will only see int16 inputs in conv. Does that answer you question?
I am sort of inclining towards going for schedule, because it is contained in one place for now. And one can easily change if one decides to use tensorize. Legalize might throw schedule developers off who want to see int8 inputs, and are surprised to see int16 inputs.

Thanks for your kind explanation @anijain2305 . That is exactly my consideration as the legalization approach may confuse tensorie implementation.

@ajtulloch it would be great if you can manage this PR, you should have the permission to approve and merge

@jackwish Thanks! Can you please review and let me know if you have more comments?
@ajtulloch Let me know if you have any comments.

Yeah, I think the schedule approach makes more sense to me as well.

ping @anijain2305

Closing as this is not relevant anymore given parallel efforts for improving int8 conv schedules


🐛 Biome LSP is treating typescript files as if they were javascript files

Environment information
CLI:
  Version:                      1.8.3
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v21.4.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 false

Workspace:
  Open Documents:               0

What happened?
I'm using neovim. The first TypeScript file that I open is treated correctly as a TypeScript file, but every other TypeScript file after that is analyzed as if it were a JavaScript file, and it throws syntax warnings about the types.
Here are the server logs for one of the incorrect lints:
└─┐biome_lsp::handlers::analysis::code_actions{uri=file:///Users/lynn/Code/Graveflex/nextjs-vercel/apps/web/src/app/(app)/%5blocale%5d/page.tsx, range=Range { start: Position { line: 38, character: 57 }, end: Position { line: 38, character: 57 } }, only=No
ne, diagnostics=[]}
  ├─  0ms DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module
_kind: Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Graveflex/nextjs-vercel/apps/web/src
/app/(app)/[locale]/page.tsx" }
  ├─  0ms DEBUG biome_service::workspace The file has the following feature sets:
  │ {Search: FileNotSupported, OrganizeImports: Supported, Lint: Supported, Format: Supported}
  ├─  0ms DEBUG biome_lsp::handlers::analysis Cursor range 1190..1190
  ├─  0ms DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module
_kind: Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Graveflex/nextjs-vercel/apps/web/src
/app/(app)/[locale]/page.tsx" }
  └─┐biome_service::file_handlers::javascript::code_actions{}
    └─┐biome_service::file_handlers::javascript::Code actions JavaScript{range=1190..1190, path=BiomePath { path: "/Users/lynn/C
ode/Graveflex/nextjs-vercel/apps/web/src/app/(app)/[locale]/page.tsx" }}
    ┌─┘
  ┌─┘
  ├─  1ms DEBUG biome_lsp::handlers::analysis Pull actions result: PullActionsResult { actions: [] }
  ├─  1ms DEBUG biome_lsp::handlers::analysis Suggested actions:
  │ []
┌─┘

You can see in the filename that it's a .tsx file, but for whatever reason it's assuming language: JavaScript instead of language: TypeScript.
Here is the relevant part of my neovim config:
return {
  'VonHeikemen/lsp-zero.nvim',
  branch = 'v4.x',
  lazy = false,
  dependencies = {
    'williamboman/mason.nvim',
    "williamboman/mason-lspconfig.nvim",
    "neovim/nvim-lspconfig",
    "jose-elias-alvarez/nvim-lsp-ts-utils",
    'hrsh7th/cmp-nvim-lsp',
    -- "WhoIsSethDaniel/mason-tool-installer.nvim",
  },
  config = function()
    local lsp_zero = require('lsp-zero')
    local mason_lspconfig = require("mason-lspconfig")

    local lsp_attach = function(client, bufnr)
      local opts = {buffer = bufnr}
    end

    local lsp_servers = {
      'lua_ls',
      'rust_analyzer',
      'ts_ls',
      'biome',
      'eslint',
      'slint_lsp',
      'cssls',
      'dockerls',
      'dotls',
      'graphql',
      'html',
      'yamlls',
      'solargraph',
      'phpactor'
    }

    lsp_zero.extend_lspconfig({
      sign_text = true,
      lsp_attach = lsp_attach,
      capabilities = require('cmp_nvim_lsp').default_capabilities(),
    })

    lsp_zero.setup_servers(lsp_servers)

    require('mason').setup({})
    require('mason-lspconfig').setup({
      ensure_installed = lsp_servers,

      handlers = {
        function(server_name)
          require('lspconfig')[server_name].setup({})
        end,
      }
    })
  end,
  keys = {
    -- format keymaps
    { '<leader>f', vim.lsp.buf.format, desc = 'LspFormat' },

    -- lsp keymaps
    { "gD", vim.lsp.buf.type_definition, desc = 'LspGotoDef' },
    { "gi", vim.lsp.buf.implementation, desc = 'LspGotoImp' }
  }
}

I don't have this same problem with the eslint LSP (or any other LSP).
Expected result
It should always lint TypeScript files using TypeScript rules, not JavaScript rules.
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

The problem was my neovim config. I removed the lsp_attach method and it started working correctly.
The fix was:
    lsp_zero.extend_lspconfig({
      sign_text = true,
      -- lsp_attach = lsp_attach, <-- remove this line
      capabilities = require('cmp_nvim_lsp').default_capabilities(),
    })

scratch my last comment. the issue is still happening, it's just intermittent

Can you post your biome config? And does biome still treat it as jsx instead of tsx from the CLI?

hi @dyc3 ! thanks for taking a look. here's our biome config:
{
  "$schema": "https://biomejs.dev/schemas/1.8.3/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  },
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineEnding": "lf",
    "lineWidth": 80,
    "attributePosition": "auto"
  },
  "organizeImports": { "enabled": true },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": false,
      "a11y": {
        "noAccessKey": "error",
        "noAriaUnsupportedElements": "error",
        "noAutofocus": "error",
        "noBlankTarget": "error",
        "noDistractingElements": "error",
        "noHeaderScope": "error",
        "noInteractiveElementToNoninteractiveRole": "error",
        "noNoninteractiveElementToInteractiveRole": "error",
        "noNoninteractiveTabindex": "error",
        "noPositiveTabindex": "error",
        "noRedundantAlt": "error",
        "noRedundantRoles": "error",
        "useAltText": "error",
        "useAnchorContent": "error",
        "useAriaActivedescendantWithTabindex": "error",
        "useAriaPropsForRole": "error",
        "useButtonType": "error",
        "useHeadingContent": "error",
        "useHtmlLang": "error",
        "useIframeTitle": "error",
        "useKeyWithClickEvents": "error",
        "useKeyWithMouseEvents": "error",
        "useMediaCaption": "error",
        "useValidAnchor": "error",
        "useValidAriaProps": "error",
        "useValidAriaRole": {
          "level": "error",
          "options": { "allowInvalidRoles": [], "ignoreNonDom": false }
        },
        "useValidAriaValues": "error",
        "useValidLang": "error"
      },
      "complexity": {
        "noBannedTypes": "error",
        "noExtraBooleanCast": "error",
        "noMultipleSpacesInRegularExpressionLiterals": "error",
        "noUselessCatch": "error",
        "noUselessConstructor": "error",
        "noUselessFragments": "error",
        "noUselessLabel": "error",
        "noUselessLoneBlockStatements": "error",
        "noUselessRename": "error",
        "noUselessTernary": "error",
        "noUselessThisAlias": "error",
        "noUselessTypeConstraint": "error",
        "noVoid": "error",
        "noWith": "error",
        "useArrowFunction": "off",
        "useLiteralKeys": "error",
        "useRegexLiterals": "error"
      },
      "correctness": {
        "noChildrenProp": "error",
        "noConstAssign": "error",
        "noConstantCondition": "warn",
        "noConstructorReturn": "error",
        "noEmptyCharacterClassInRegex": "error",
        "noEmptyPattern": "error",
        "noGlobalObjectCalls": "error",
        "noInnerDeclarations": "error",
        "noInvalidConstructorSuper": "error",
        "noInvalidUseBeforeDeclaration": "error",
        "noNewSymbol": "error",
        "noNodejsModules": "off",
        "noNonoctalDecimalEscape": "error",
        "noPrecisionLoss": "error",
        "noSelfAssign": "error",
        "noSetterReturn": "error",
        "noSwitchDeclarations": "error",
        "noUndeclaredVariables": "error",
        "noUnreachable": "error",
        "noUnreachableSuper": "error",
        "noUnsafeFinally": "error",
        "noUnsafeOptionalChaining": "error",
        "noUnusedLabels": "error",
        "noUnusedPrivateClassMembers": "off",
        "noUnusedVariables": "error",
        "noVoidElementsWithChildren": "error",
        "useArrayLiterals": "off",
        "useExhaustiveDependencies": "error",
        "useIsNan": "error",
        "useJsxKeyInIterable": "error",
        "useValidForDirection": "error",
        "useYield": "error"
      },
      "security": {
        "noDangerouslySetInnerHtml": "warn",
        "noDangerouslySetInnerHtmlWithChildren": "error",
        "noGlobalEval": "error"
      },
      "style": {
        "noArguments": "error",
        "noCommaOperator": "error",
        "noDefaultExport": "off",
        "noImplicitBoolean": "error",
        "noNamespace": "error",
        "noNegationElse": "off",
        "noParameterAssign": "error",
        "noRestrictedGlobals": {
          "level": "error",
          "options": {
            "deniedGlobals": [
              "isFinite",
              "isNaN",
              "addEventListener",
              "blur",
              "close",
              "closed",
              "confirm",
              "defaultStatus",
              "defaultstatus",
              "event",
              "external",
              "find",
              "focus",
              "frameElement",
              "frames",
              "history",
              "innerHeight",
              "innerWidth",
              "length",
              "location",
              "locationbar",
              "menubar",
              "moveBy",
              "moveTo",
              "name",
              "onblur",
              "onerror",
              "onfocus",
              "onload",
              "onresize",
              "onunload",
              "open",
              "opener",
              "opera",
              "outerHeight",
              "outerWidth",
              "pageXOffset",
              "pageYOffset",
              "parent",
              "print",
              "removeEventListener",
              "resizeBy",
              "resizeTo",
              "screen",
              "screenLeft",
              "screenTop",
              "screenX",
              "screenY",
              "scroll",
              "scrollbars",
              "scrollBy",
              "scrollTo",
              "scrollX",
              "scrollY",
              "self",
              "status",
              "statusbar",
              "stop",
              "toolbar",
              "top"
            ]
          }
        },
        "noUselessElse": "error",
        "noVar": "error",
        "useAsConstAssertion": "error",
        "useBlockStatements": "error",
        "useCollapsedElseIf": "error",
        "useConst": "error",
        "useDefaultParameterLast": "error",
        "useExponentiationOperator": "error",
        "useFragmentSyntax": "error",
        "useImportType": "error",
        "useNumericLiterals": "error",
        "useShorthandAssign": "error",
        "useSingleVarDeclarator": "error",
        "useTemplate": "error"
      },
      "suspicious": {
        "noArrayIndexKey": "error",
        "noAssignInExpressions": "error",
        "noAsyncPromiseExecutor": "error",
        "noCatchAssign": "error",
        "noClassAssign": "error",
        "noCommentText": "error",
        "noCompareNegZero": "error",
        "noConfusingLabels": "error",
        "noConsoleLog": "warn",
        "noControlCharactersInRegex": "error",
        "noDebugger": "error",
        "noDoubleEquals": "error",
        "noDuplicateCase": "error",
        "noDuplicateClassMembers": "error",
        "noDuplicateJsxProps": "error",
        "noDuplicateObjectKeys": "error",
        "noDuplicateParameters": "error",
        "noEmptyBlockStatements": "error",
        "noExplicitAny": "error",
        "noExtraNonNullAssertion": "error",
        "noFallthroughSwitchClause": "error",
        "noFunctionAssign": "error",
        "noGlobalAssign": "error",
        "noImportAssign": "error",
        "noLabelVar": "error",
        "noMisleadingCharacterClass": "error",
        "noMisleadingInstantiator": "error",
        "noPrototypeBuiltins": "error",
        "noRedeclare": "error",
        "noSelfCompare": "error",
        "noShadowRestrictedNames": "error",
        "noUnsafeDeclarationMerging": "error",
        "noUnsafeNegation": "error",
        "useAwait": "off",
        "useDefaultSwitchClauseLast": "error",
        "useGetterReturn": "error",
        "useValidTypeof": "error"
      }
    },
    "ignore": [
      "**/node_modules/**",
      "**/dist/**",
      "**/storybook-static/**",
      "**/.next/**"
    ]
  },
  "javascript": {
    "globals": ["describe", "it"],
    "formatter": {
      "jsxQuoteStyle": "double",
      "quoteProperties": "asNeeded",
      "trailingCommas": "none",
      "semicolons": "always",
      "arrowParentheses": "always",
      "bracketSpacing": true,
      "bracketSameLine": false,
      "quoteStyle": "single",
      "attributePosition": "auto"
    }
  },
  "overrides": [
    { "include": ["*.json"], "formatter": { "indentWidth": 2 } },
    {
      "include": ["*.test.ts*"],
      "javascript": {
        "globals": ["it", "describe"]
      }
    }
  ],
  "files": {
    "ignore": [
      "**/node_modules/**",
      "**/dist/**",
      "**/storybook-static/**",
      "**/.next/**",
      "apps/web/src/migrations/**",
      "**/importMap.js",
      "**/payload-types.ts"
    ]
  }
}

This is what we got from an eslint migration so it might be more complicated than it needs to be.

And no, when i run biome from the CLI, everything is fine. Both biome check and biome check --write work as expected.

It could be your IDE is reporting the file incorrectly. I'm pretty sure this is what the LSP uses to determine the language:
https://github.com/biomejs/biome/blob/83e5cef0d1443559f888cbbdd6e40b0fe228df01/crates/biome_js_syntax/src/file_source.rs#L320-L326

I'm in neovim, and when I check the filetype with :set filetype? it seems to be coming back with the correct filetype (either filetype=typescript or filetype=typescriptreact). And also this has never happened with the eslint LSP (or any other LSP that I've used).
Is there anything different about how filetypes are derived with the biome LSP compared to the eslint LSP?

I'm not sure tbh. I'm still not super familiar with how the LSP works.
You mentioned that it was intermittent: It could be there's some race condition somewhere. I'm assuming that you checked the filetype while the bug was happening?

It must be something like that, but I don't know how to go about testing for the race condition.
Neovim was reporting the correct filetype while the error was present.
I did running :LspRestart but it didn't seem to have any effect.
Also if it was a race condition, I would imagine that subsequent requests to the LSP would communicate the correct filetype, but the biome logs continue to show the filetype as language: JavaScript.

@Conaclos i saw that a release just went up with added debugging output. Here is a log capture of this issue happening with the latest version that just went out (1.9.0):
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module_kind:
Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[loc
ale]/layout.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), was_written: false }
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace The file has the following feature sets:
│ {OrganizeImports: Supported, Search: Supported, Assists: Supported, Lint: Supported, Format: Supported}
├─ DEBUG biome_lsp::handlers::analysis Cursor range 1244..1244
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module_kind:
Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[loc
ale]/layout.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), was_written: false }
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx
"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/la
yout.tsx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::javascript::code_actions{}
  └─┐biome_service::file_handlers::javascript::Code actions JavaScript{range=Some(1244..1244), path=BiomePath { path: "/Users/ly
nn/Code/Dutch/dutchtest/apps/web/src/app/(app)/[locale]/layout.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), w
as_written: false }}
  ┌─┘
┌─┘
├─ DEBUG biome_lsp::handlers::analysis Suggested actions:
│ []

Also here's a screenshot of my editor while the issue is present:

Ok now we at least know it's not using the language id to determine the language. I forgot to put the returned values in the new logs, but just from this it seems like try_from_extension is determining the file is JavaScript.
I won't be able to take a closer look for a while.

I think I know the source for the problem, but not what causes it.
The LSP only calls from_language_id when it receives the textDocument/didOpen LSP notification. When grabbing the file capabilities, the path is used, not the language id.
https://github.com/biomejs/biome/blob/9261b752338f7dfb46d2b5099133240ad8d3c301/crates/biome_service/src/workspace/server.rs#L115-L121
Something is happening that is causing these 2 fields on the WorkspaceServer to get out of sync.
https://github.com/biomejs/biome/blob/9261b752338f7dfb46d2b5099133240ad8d3c301/crates/biome_service/src/workspace/server.rs#L49-L50
https://github.com/biomejs/biome/blob/9261b752338f7dfb46d2b5099133240ad8d3c301/crates/biome_service/src/workspace/server.rs#L55-L56
I imagine it hasn't come up before if the neovim LSP client sends requests in a different order than the VSCode LSP client.

I'll see about getting a new nightly released with the adjusted debug logs. If you could get trace level logs, that would be great.

Thank you @dyc3 ! I'll test as soon as the build goes up.

The new nightly is up: https://github.com/biomejs/biome/releases/tag/cli%2Fv1.9.1-nightly.12688b6

Sorry for the delay @dyc3 . Just updated to v1.9.1, here are the logs during the issue:
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module_kind:
Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemePro
vider.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), was_written: false }
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace The file has the following feature sets:
│ {Assists: Supported, Format: Supported, Lint: Supported, OrganizeImports: Supported, Search: Supported}
├─ DEBUG biome_lsp::handlers::analysis Cursor range 0..0
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
├─ DEBUG biome_service::workspace::server File capabilities: Js(JsFileSource { language: JavaScript, variant: Jsx, module_kind:
Module, version: ES2022, embedding_kind: None }) BiomePath { path: "/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemePro
vider.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), was_written: false }
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::try_from_path{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx"}
  └─┐biome_service::file_handlers::try_from_well_known{path="/Users/lynn/Code/Dutch/dutchtest/packages/theme/src/ThemeProvider.t
sx"}
  ┌─┘
  └─┐biome_service::file_handlers::try_from_extension{extension="tsx"}
  ┌─┘
┌─┘
└─┐biome_service::file_handlers::javascript::code_actions{}
  └─┐biome_service::file_handlers::javascript::Code actions JavaScript{range=Some(0..0), path=BiomePath { path: "/Users/lynn/Cod
e/Dutch/dutchtest/packages/theme/src/ThemeProvider.tsx", kind: FileKinds(BitFlags<FileKind>(0b10000, Handleable)), was_written:
false }}
  ┌─┘
┌─┘
├─ DEBUG biome_lsp::handlers::analysis Suggested actions:
│ []

@dyc3 hey just making sure you saw my last comment

Thanks, this slipped through the cracks.

Honestly, I'm a bit stumped with this one. I think it would be easier if I could reproduce it on my own machine. I've never used neovim before, is the config you posted above sufficient for me to use? Also, could you narrow down the steps required to reproduce?

I can consistently reproduce the problem by openening up a next.js monorepo project and then opening 2 or 3 typescript files. The first one is usually ok, but after the 2nd or 3rd file, each new file is classified as a JavaScript file.
@dyc3 my entire neovim config is up here. i think this file is the only one needed to reproduce, but it gets loaded by this file along with some other basic config.
My config might not be the best starting point for nvim. You might be better off using a pre-built config like LazyVim LunarVim or NvChad. The LSP servers are typically managed by a system called mason.nvim.
I'm also happy to do a screen recording if it would be helpful, just let me know what you want to see.

I'll give it a shot tomorrow. It would be super useful to have a repo already set up. You can use our helper to automate that a little with your preferred package manager:
npm create @biomejs/biome-reproduction

pnpm create @biomejs/biome-reproduction

bun create @biomejs/biome-reproduction

yarn create @biomejs/biome-reproduction

I tried what you said in neovim in a react project, using lazyvim and only adding this to the init.lua:
require'lspconfig'.biome.setup{}

I was not able to reproduce the issue. A screen recording would be good to see exactly what you are doing.

@dyc3 i just switched my config to LazyVim and I haven't been able to reproduce for the past few days.
At this point I'm guessing that my plugins were being initialized in a different order.
I'm going stick with LazyVim as the base for my config, and if the issue comes back I'll re-open this ticket with more info.
Thank you for the effort that you put into debugging this for me.

I'm having this issue as well with mason/biome, except my config is lazyvim.
I see that the issue only happens with biome version 1.6.0 up. I set the version like this in neovim: :MasonInstall<EMAIL_ADDRESS>It is not clear to me if this is an issue with biome, mason or something, but at least I can use biome without this warning.


not open crop activity when in click on image

not work CropImage.activity()                     .setGuidelines(CropImageView.Guidelines.ON)                     .setAspectRatio(1,1)                     .start(this);

Same Problem..

When I launched my app on my device it's work only one time. But when I clear it from cache and restart app and then try to crop new Image then activity started but before selecting any Image to crop it have been finished. I don't know but it is not working properly.

Hey!
I start a new project to handover this library
https://github.com/CanHub/Android-Image-Cropper
The ideia is that we keep improving because this project don’t have updates since 2018
Hope I can count with your help.
Open to contribute, next pieces of work will be Android 11 permissions, refactor into Kotlin and ActivityContract


Draggable freeze when it's child changed.

I am writing this issue due to my experience that when the content of the draggable dynamically change it freezes for 2 - 5 seconds.
I'm using the latest react-draggable version
Related issue
On the function matchesSelectorAndParentsTo() on domfns.js we can add a try catch when checking matchesSelector to filter out this error.
Hope i can help to this issue.

@STRML i have a fix for this. if you could let me push my branch and create a PR


Redrawing hangs forever

If you put the Iceberg Repositories Browser on top left of your Pharo window, whenever you do an action it will hang on redrawing. This is because the messages on top left force a redrawing that might fire a git command that in turn will add another message that starts redrawing again.

To reproduce, place the repositories browser image close to the upper left corner and run in a playground:
UIManager default informUser: 'Foo' during: [
UIManager default informUser: 'Bar' during: [
IceRepository registry first push ]]

As of version https://github.com/npasserini/iceberg/commit/13cfbaf9c7507a63655fb1ae6a13385863399f64 it does not seem to happen any more. Closing.

I closed the wrong issue.

This is fixed for the repositories browser, but will require more work for the commit browser. Postponing to the next version.

Fixed in https://github.com/npasserini/iceberg/commit/883c2a1d2a3b26c52b43c17334204d55ff31394a


Specify a max depth?

Would it be possible to specify a maximum depth for the analysis of the XML? In my case, I need to analyse my XMLs till a depth of 2, and maybe having such an option could speed up the process? The value of the maximum node could be simply a string (non parsed xml).

I don't think that's possible, since the SAX parser processes the XML sequentially from first to last byte, without caring about the depth of the document. And when the XML parser is processing the whole file anyway, it wouldn't save much processing time if at all.


Need to allow complex inputs

The main application for vectfit is when the input values s are imaginary, and the output values f are complex.  But your program only allows s and f to be real.  Do you think you could modify the program so that it can do this?
The original matlab program can do this.  And the examples given in the original paper are of this form.

There is no longer active development on vectfit since it has been integrated in OpenMC and has worked well as is for our purposes.  Our main use case is for input values that are real and output values that are complex.

From: stephenmontgomerysmith @.>
Sent: Wednesday, May 31, 2023 8:22 PM
To: mit-crpg/vectfit @.>
Cc: Subscribed @.***>
Subject: [mit-crpg/vectfit] Need to allow complex inputs (Issue #3)
The main application for vectfit is when the input values s are imaginary, and the output values f are complex. But your program only allows s and f to be real. Do you think you could modify the program so that it can do this?
The original matlab program can do this. And the examples given in the original paper are of this form.
—
Reply to this email directly, view it on GitHubhttps://github.com/mit-crpg/vectfit/issues/3, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHXBLX5WVN657EXONR36M3XI7OGFANCNFSM6AAAAAAYWFOT2E.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


snack example not working

SNACK EXAMPLE NOT WORKING, IT IS SIMPLY CRASHING WHEN  I TRY TO RUN IT
https://snack.expo.dev/@computerjazz/draggable-flatlist-examples?platform=ios

@MrFarhan check the expo version you are running the example on. It should be expo 48