An attempt to install without docker privileges

Ubuntu 22.04
CUDA: 12.2

clone repo
create conda python env: conda create -n xxx python=3.10
install some dependencies:
conda install gcc_linux-64 git-lfs
pip install cmake
git lfs:
git lfs install
git lfs pull
install requirements:
pip install -r requirements.txt -i https://pypi.douban.com/simple
If the error 'mpi.h' is not found occurs
Install openmpi tar from https://www.open-mpi.org. (I installed openmpi-4.1)
download TensorRT tar from https://developer.nvidia.com/downloads/compute/machine-learning/tensorrt/secure/9.1.0/tars/TensorRT-<IP_ADDRESS>.Linux.x86_64-gnu.cuda-12.2.tar.gz
tar -xvf the tar_file and noted the TensorRT path
download nccl from NVIDIA web(I install nccl_2.19.3)
tar -xvf the tar_file and noted the nccl path
download cudnn_cuda12 version 8.xx
untar and copy the lib/ to cuda/lib64 and inlcude to cuda/include
if you not have the permission of cuda
you should hack scripts/build_wheel.py(124L)
add CUDNN_ROOT_DIR just looks like NCCL_LIB_DIR
export LD_LIBRARY_PATH=xxx/TensorRT path/lib:$LD_LIBRARY_PATH
export TORCH_INSTALL_TYPE="skip"
python scripts/build_wheel.py --clean --trt_root xxx/TensorRT path --nccl_root xxx/nccl path
Compile to 98% and it will lag for a while (5-10mins)
pip uninstall tensorrt(8.6.1)
pip install tensorrt==9.1.0.post12.dev4 --no-cache-dir --extra-index-url https://pypi.nvidia.com

Relevant issue
https://github.com/NVIDIA/TensorRT-LLM/issues/22
https://github.com/NVIDIA/TensorRT-LLM/issues/286
https://github.com/NVIDIA/TensorRT-LLM/issues/342
....

works for me. Thank you !

Close this bug because the issue is resolved. Feel free to ask here if you still have question/issue, we will reopen the issue.

Also works for me, thank you!


Missing APIs for bookmarks

Hello, are you planning to support the following bookmarks APIs?

bookmarks.onCreated
bookmarks.onRemoved
bookmarks.onChanged
bookmarks.onMoved

Please visit this link for reference: https://developer.chrome.com/extensions/bookmarks
Thanks in advance.

Hi @SciFreakholic, our UserVoice channel is the place for Edge platform requests. Please do file that!


Avoid duplicated code between the common config and the react config

on a side note, can't the react config inherit from the base file, just so that we don't have all this duplication?

I tried it at the beginning, but the order matters. There were settings from the common part that they need to go after some other parts from the react config.
Maybe a solution is to make it more module to avoid duplications

ah ok, yeah that makes things a bit more complicated. maybe then only for parts that don't depend on the order like the rules?
Originally posted by @FlorinSenoner in https://github.com/valtech-ch/eslint-config/issues/6#issuecomment-838114030

Fixed in #8


[Fastlane] Info.plist from UnitTest target overrides values read from config_file

Expected behavior
send_build_to_bugsnag(config_file: application.info_plist_path)

Above code should read appVersion from the given config_file.
Observed behavior
appVersion reported to bugsnag is taken from UnitTests/Info.plist.
Steps to reproduce

Have a unit test target with an Info.plist.
Have an app target with a letter that begins with a letter later than U in the alphabet, (our case: V).
send_build_to_bugsnag(config_file: "App/Info.plist")

Version
fastlane-plugin-bugsnag (1.3.0)
Additional information
This happens because of two issues.

default_info_plist_path is used despite providing a config_file, unfortunately default_info_plist_path returns the wrong Info.plist.
The default plist path is used to populate the default params
Default params override any values from config_file-specified, due to the order they're read, see here: https://github.com/bugsnag/bugsnag-dsym-upload/blob/be109217a611ec49a34828c2026fced0a8f1bc8e/tools/fastlane-plugin/lib/fastlane/plugin/bugsnag/actions/send_build_to_bugsnag.rb#L10-L25

Code linked assumes that params are only explicitly set by the user, but params also contains default values, which happens to be provided by the default_info_plist_path, which in my particular case finds the wrong Info.plist because UnitTests/Info.plist appears before our app V/Info.plist in directory listings.

Thank you for the detailed report, @Burgestrand. I think there a few approaches we can take to improve the config file/params resolution.

Exclude test Info.plist files by default - there is already similar logic for Info.plist files found in build directories.
If config_file is changed from the default value, require API key, app version, and bundle version to be loaded from there.

I've made a start on these changes which will go into a new patch release.

Thanks! Yes, I believe 2 would be enough to solve it in my specific case!

Well, 1 should solve your specific case by automatically detecting the right Info.plist file more often. Ideally no one should ever have to set config_file at all :)

Thank you for the Swift fix!
I just now found that the default search path for default_info_plist_path only goes a single level (I don't know why I didn't catch this before), and because of my Info.plist being buried 3 levels deep it's not included in the list at all (although when it is, it would still not have been the first one in the list so the fix was not in vain 😄).
It's not a problem for me due to your fix in 2, but I felt it was worth mentioning. My directory structure looks like so:
.
├── UnitTests
│   └── Info.plist
├── VideoApp
│   ├── Application
│   │   └── Assets
│   │       └── Info.plist <~~~ Here it is!
│   └── … there's way more stuff here! …
├── VideoApp.playground
├── VideoApp.xcodeproj
├── VideoApp.xcworkspace
└── fastlane

Thanks for the feedback @Burgestrand, the structure diagram is helpful. The intent behind only going a single level was to avoid catching Info.plist files from Pods, Carthage/Build, build artifacts, etc, though maybe this is something to consider as well. I'm glad the fix is working and will consider how we could better detect the config file for cases like this.


Refactor location and format of all available commands

Looking at the server setup, Commands are never setup in any kind of config. And they appear to be added in 2 places. Commands for running launchpad from the CLI, and commands from with Launchpad itself. I think the two places makes sense. But the server now needs to know about the commands, so we need to config them or something.
considering these 2 places, do we need two types of commands, CLI and internal to launchpad(?)?
CC: @benjaminbojko

A central spot, possibly a static array or enum in the Command class makes the most sense to me.
That way we could use a simple filter/reduce function to configure yargs (to include/exclude certain commands for startup), and the server package could expose all of those commands to the API via a simple iteration or lookup. It might even be nice if the server doesn't store any list of commands internally and simply does a check for whether a command exists once it receives a request, or iterates over all available commands to create routes (e.g. for REST).

PS: renamed the ticket to make it more actionable/clear what this is about

Agreed on the iterable part! I like the idea of creating things on the fly, BUT do we ever see in the future where we may want to limit specific routes for the server or specific transports? I guess we can add more to the config to define that... but just curious.

OK - didn't take a full stab at this yet, but this could be bigger than smaller. Not sure if this should be done before we try to launch the server, or if we should launch the server, then figure out what we need in this central commands thing.

It felt like this could be a fairly targeted incision, but I hear you on it feeling like it might have implications. It doesn't seem like it would limit functionality wildly.
Maybe a first step is just moving the StartupCommands enum from ./packages/launchpad/index.js to the CommandCenter class and leaving the rest as is?
And in regards to limiting specific routes: Yes, that's sort of what I meant! We could use the set of available commands and only allow routes that are valid commands, and return 404 or 401 accordingly.

So... should Command Center be treated as a singleton?

Hmm that's a good question. Technically yes, there should only be one instance.
The only other actual singleton right now is the LogManager class. I wonder if we should make Launchpad a singleton and then expose the CommandCenter instance there via a getter. I worry about opening the door too much to wires getting crossed amongst packages, so maybe forcing things to go through Core will keep things at least somewhat centralized.
FWIW I'm still passing the _logger instance to each package as a constructor argument. I believe the singleton is only used in testing and other scenarios.
What do you think?

I don't know.... these are great questions!
So, which is first/primary? The command center or Launchpad?
use case: Adding a user. This "could be" a command, but launchpad-core doesn't need to do anything with it and it is a command line only command. So its a waste to load launchpad-core to run that type of command.

OR -

Launch-pad core is considered central and EVERYTHING needs to run through launchpad-core. Even adding a new user.
...
I'm now wondering too... could the command center be used for the dashboard as well? So its now a whole new new Config-like object (but its only defined in code - maybe we can enable/disable commands from config but not create new commands). Anything and everything can build out how it needs to based on that Command Center.
The more I'm typing i'm thinking thats the way to go... Let me branch off the server branch and play a bit.

OK - naming might be bad... that class maybe should be CmmandCenterConfig or something since it should replace the existing CommandCenter that is in core.

Thanks for pushing on this and giving this more thought! Super helpful to have something to look at and discuss.
I'd like to hear more about what you were thinking about configuring each protocol on a per-command basis. I was thinking that protocol-specific paths, message would either be a config in the transport layer or hard-coded. If the transport classes convert whatever messages they receive to these standardized commands then, then we can add/modify those transports whenever and don't need to keep updating this core spec. They could even be their own npm modules eventually for easer extensibility (e.g. specific project APIs). Feels cleaner to me to have that all decoupled.
Sidebar: The more I think about it, the more I question whether the HTTP server should actually be always on. It feels like that should actually just be one of the transport layers. That's a separate issue though #18 #14 :)
For the code, I was hoping to leverage what we already have more:
export class Command {
  /**
   This class already exists in `command-center.js`:
   https://github.com/bluecadet/launchpad/blob/main/packages/launchpad/lib/command-center.js#L121-L164

   The `name` property could be renamed to `id` if needed.

   We could switch the callbacks on each command to events,
   so that the `LaunchpadCore` class subscribes to those instead
   of dictating what the callback is within the command itself.
   That would allow other classes to also digest those events.
   */
}

// Then we have a class, enum or frozen object (`Object.freeze({...})`) that lists out all available commands
export class Commands {
  static START = new CommandSpec({id: 'start', /* ... */});
  static STOP = // ...
}

Let me know what you think!

sidebar first: yea, in config the server as a whole should be able to be enabled or disabled as well as the individual transports. Its a little weird bc theres overlap with http and websockets but I think its handled. If you're talking about the enabled in each command, i was thinking an easy option would be to allow/disallow each command on each transport. So for example OSC, you can only trigger content download, but can't stop launchpad
Yea the more I played with this yesterday, the more I got confused and annoyed.. ha! I'm not in love with what I was thinking anymore. I was thinking the Command class was getting implemented too late in the process so was thinking we need config at the beginning. Add rather than refactor. And a little bit here I just didn't understand your thoughts and direction for the Command class.
One reason I was thinking it needs to be a separate config thing, is that a lot should be hard coded, but what if we need ???... I don't know at the moment, but not trying to lock in too much. Just the nature of OSC does seem like we are going to need to be able to config the address and values. And the nature of http and websockets, we can easily hard code those endpoints.
So:

Should this be "solved" before the whole server is ready? Might be good to get the server almost ready so we understand what it really needs.
This might be something worth having a convo over and planning properly


make it so that it will create all the intermediate-level directories…

make it so that it will create all the intermediate-level directories…, otherwise will fail import into custom_node
Error
Using xformers cross attention
module_name is ComfyUI_FizzNodes
Making the "web\extensions\FizzleDorf" folder
Traceback (most recent call last):
  File "/workspace/ComfyUI/ComfyUI-to-Python-Extension/../nodes.py", line 1735, in load_custom_node
    module_spec.loader.exec_module(module)
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/workspace/ComfyUI/custom_nodes/ComfyUI_FizzNodes/__init__.py", line 20, in <module>
    os.mkdir(extentions_folder)
FileNotFoundError: [Errno 2] No such file or directory: '/workspace/ComfyUI/ComfyUI-to-Python-Extension/web/extensions/FizzleDorf'

Cannot import /workspace/ComfyUI/custom_nodes/ComfyUI_FizzNodes module for custom nodes: [Errno 2] No such file or directory: '/workspace/ComfyUI/ComfyUI-to-Python-Extension/web/extensions/FizzleDorf'
module_name is ComfyUI-Advanced-ControlNet
module_name is ComfyUI-VideoHelperSuite

For context, https://github.com/pydn/ComfyUI-to-Python-Extension/issues/19

thanks for your contribution!


View class and prototype, memory efficiency question

Hello, I'm looking over the source code and have noticed that when a new view is instantiated via
var myView = new View(..);
Every single function is created all over again because prototypes are not being used. I was curious if this was by intention and what the purpose is.
I will elaborate here:
The "new" statement creates pointers to all the functions attached to the "prototype" attribute.
I hope I'm not being too pedantic as I'm sure you're well aware of this, I'm asking this for the sake of making my question complete:
var Demo = function(){
  this.testA = function(){return 1}
}
Demo.prototype.testB = function(){return 2}

var a = new Demo()
var b = new Demo()

Demo.testA = function(){return 3}
Demo.prototype.testB = function(){return 3}

console.log(a.testA()) // returns 1
console.log(a.testB()) // returns 3

The method testA is attached to the instance not to the class. Every instance has its own copy, which takes up memory.
The method testB, attached to the prototype attribute, is attached to the class. Every instance references the same copy (unless overwritten).
In the source code I noted:
app.addView = function (selector, params) {
            return new View(selector, params);
};

Every call to addView creates a new instance and therefore, a new copy of all the functions attached to this in view
var view = this

If the intention is to have class wide variables, shared by all instances, one could leverage a closure:

var Demo = (function()){
  var classAttribute = 1

  var Demo = function(){
    this.instanceAttribute = 2
  }

  Demo.prototype.method = function(){}

  return Demo
)()

The intention was different, to make each View as closed and separate from another as much as possible. And it is not really a question about overwrite parameters/methods as you wouldn't and shouldn't do it)) But performance/memory question is interesting, but Views are not used such often, you probably have up to 5 instances maximum in app. So is there any chance to estimate how much we can win with rewriting it to prototypes ?:)


replace gophercloud/utils with go-bits/gophercloudext

As expected, this removes several transitive dependencies, including gopkg.in/yaml.v3.

coverage: 67.584% (+0.5%) from 67.122%
when pulling b1ce38eea70e7145d0cdf4930f07254db612b498 on new-go-bits
into 541878d105981d51e021a010d952bd587ad8fa29 on main.


__STATIC_CONTENT_MANIFEST error when bundling with Cloudflare's wrangler.

When using<EMAIL_ADDRESS>for Cloudflare's Workers, when bundling with Wrangler or ESbuild I get this error when importing serveStatic from hono/cloudflare-workers
✘ [ERROR] Could not resolve "__STATIC_CONTENT_MANIFEST"

    node_modules/hono/dist/adapter/cloudflare-workers/server-static-module.js:2:21:
      2 │ import manifest from "__STATIC_CONTENT_MANIFEST";
        ╵                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "__STATIC_CONTENT_MANIFEST" as external to exclude it
  from the bundle, which will remove this error.

1 error

Even when I mark it as external and exclude it form the bundle When running the worker I get an error stating Uncaught SyntaxError: Cannot use import statement outside a module

Hi @JeffBue,
Try using esbuild with this command:
esbuild --outdir=dist --external:__STATIC_CONTENT_MANIFEST --bundle ./src/index.ts

But it shouldn't throw an error when using Wrangler.

Even when I mark it as external and exclude it form the bundle When running the worker I get an error stating Uncaught SyntaxError: Cannot use import statement outside a module

Thank you @yusukebe for responding!
As noted above

Even when I mark it as external and exclude it form the bundle When running the worker I get an error stating Uncaught SyntaxError: Cannot use import statement outside a module

Here's the command logs I get:
With no --external flag error
 ~/TCG_SITES/simple-renderer-base   main ±  npx esbuild app.js --bundle --outfile=dist/worker.js --loader:.html=text --loader:.md=text --loader:.csv=text --loader:.css=text --platform=node --watch --format=esm
✘ [ERROR] Could not resolve "__STATIC_CONTENT_MANIFEST"

    node_modules/hono/dist/adapter/cloudflare-workers/server-static-module.js:2:21:
      2 │ import manifest from "__STATIC_CONTENT_MANIFEST";
        ╵                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "__STATIC_CONTENT_MANIFEST" as external to exclude it from the bundle, which
  will remove this error.

1 error
[watch] build finished, watching for changes...
^C

With --external flag no error
 ✘  ~/TCG_SITES/simple-renderer-base   main ±  npx esbuild app.js --bundle --outfile=dist/worker.js --loader:.html=text --loader:.md=text --loader:.csv=text --loader:.css=text --platform=node --watch --format=esm --external:__STATIC_CONTENT_MANIFEST
[watch] build finished, watching for changes...

Wrangler serving compiled worker file error
 ~/TCG_SITES/simple-renderer-base   main ±  npx wrangler dev dist/worker.js --no-bundle=true
 ⛅ wrangler 3.0.1
------------------
wrangler dev now uses local mode by default, powered by 🔥 Miniflare and 👷 workerd.
To run an edge preview session for your Worker, use wrangler dev --remote
▲ [WARNING] Enabling Node.js compatibility mode for built-ins and globals. This is experimental and has serious tradeoffs. Please see https://github.com/ionic-team/rollup-plugin-node-polyfills/ for more details.

Your worker has access to the following bindings:
- Vars:
  - API_BASE_URL: "https://static-node-api-bjoyt36yaq-uc..."
  - SITE: "base"
⎔ Starting local server...
service core:user:renderer-base: Uncaught Error: Dynamic require of "__STATIC_CONTENT_MANIFEST" is not supported
  at core:user:renderer-base:13:11
  at core:user:renderer-base:271:48
  at core:user:renderer-base:8380:3
✘ [ERROR] MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.

Please let me know if this helps narrow the troubleshooting.
Also why is it necessary to always import a static package of __STATIC_CONTENT_MANIFEST ?

__STATIC_CONTENT_MANIFEST is required for using serve-static.
I believe you don't need to use the esbuild command; it's okay to use only the wrangler command. Wrangler includes esbuild internally. If you want to import files like *.html or *.md, and so on, please refer to this document:

https://developers.cloudflare.com/workers/wrangler/configuration/#bundling

__STATIC_CONTENT_MANIFEST is required for using serve-static.
I believe you don't need to use the esbuild command; it's okay to use only the wrangler command. Wrangler includes esbuild internally. If you want to import files like *.html or *.md, and so on, please refer to this document:

https://developers.cloudflare.com/workers/wrangler/configuration/#bundling

@yusukebe
Is there anyway this could be incorporated in to the package.
This fix works out in so many ways, since in local development, not using wrangler to compile, there is no resource called __STATIC_CONTENT_MANIFEST, but at run time there is a global variable.
// src/adapter/cloudflare-workers/server-static-module.ts
// import manifest from "__STATIC_CONTENT_MANIFEST";
import { serveStatic } from "./serve-static.js";
var module = (options = { root: "" }) => {
  return serveStatic({
    root: options.root,
    path: options.path,
    manifest: options.manifest ? options.manifest : __STATIC_CONTENT_MANIFEST,
    rewriteRequestPath: options.rewriteRequestPath
  });
};
export {
  module as serveStatic
};

commenting out the import and just using the global.

@JeffBue
If you follow the approach highlighted in the code, it will throw an error on Wrangler.

Therefore, you should handle __STATIC_CONTENT_MANIFEST with the builder/bundler that you use. If you're using esbuild, you can achieve this with the --format=esm option:
esbuild --external:__STATIC_CONTENT_MANIFEST --format=esm --bundle src/static.ts > ./dist/worker.js
wrangler dev ./dist/worker.js

When I start this project, I get the same error:
pnpm run dev

service core:user:worker: Uncaught Error: No such module "__STATIC_CONTENT_MANIFEST".
  imported from "index.js"

@yusukebe I'm also facing this issue. I noticed it while working on the solution for workers site at https://github.com/honojs/vite-plugins/pull/26.
This issue arises from the fact that the configuration settings for the build set by users of the hono (such as vite or tsup) cannot affect the configuration settings of the hono itself. To address this issue, it is necessary to change it to a form where the options.manifest is received externally (users explicitly import __STATIC_CONTENT_MANIFEST and pass the manifest). (In my opinion)
For example, let's say you added:

import manifest from '__STATIC_CONTENT_MANIFEST'; to src/index.ts.
add import { serveStatic } from 'hono/cloudflare-workers';. In the same file.

In this case, the imports will be resolved in the order of (1), then (2).
When building at this point, you will encounter the following error message:
[vite] Error when evaluating SSR module src/worker.ts: failed to import "__STATIC_CONTENT_MANIFEST"

Next, include global.d.ts in the build. Here, we will use Vite as an example. Vite plugins can resolve this import issue by using resolveId and load. Specifically, you can write code like the following:
// Plugin for Vite
{
    name: "example/vite-plugin",
    resolveId(id, importer, options) {
        if (id === "__STATIC_CONTENT_MANIFEST") {
            return id;
        }
        return null; // ignore other cases
    },
    load(id) {
        if (id === "__STATIC_CONTENT_MANIFEST") {
            // Provide a custom code for __STATIC_CONTENT_MANIFEST
            return `export default "{}"`;
        }
        return null;
    },
}

// global.d.ts
declare module '__STATIC_CONTENT_MANIFEST' {
  const value: string;
  export default value;
}

After this, if you build again, you will notice that the initial import issue is resolved, but now an error occurs on the hono side.
[vite] Error when evaluating SSR module src/worker.ts: failed to import "hono/cloudflare-workers"
|- Error [ERR_MODULE_NOT_FOUND]: Cannot find package '__STATIC_CONTENT_MANIFEST' imported from<EMAIL_ADDRESS>

@Code-Hex
You can avoid the error by marking __STATIC_CONTENT_MANIFEST as external. Try it with this config:
import { defineConfig } from 'vite'
import devServer from '@hono/vite-dev-server'

export default defineConfig({
  build: {
    rollupOptions: {
      external: ['__STATIC_CONTENT_MANIFEST']
    }
  },
  plugins: [
    devServer({
      entry: 'src/index.tsx'
    })
  ]
})

@yusukebe I've already tried that. I cannot avoid it

@Code-Hex
It does not throw the error with that config. I'm not sure when will you have the error. Can I reproduce that?
https://github.com/honojs/hono/pull/1804 is a breaking change, so we can merge it right now.

@yusukebe https://github.com/Code-Hex/hono-serve
You will get error message such as below:
npm run dev

> dev
> vite

  VITE v5.0.7  ready in 104 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help
(!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling.
12:15:38 [vite] Error when evaluating SSR module src/index.ts: failed to import "hono/cloudflare-workers"
|- Error [ERR_MODULE_NOT_FOUND]: Cannot find package '__STATIC_CONTENT_MANIFEST' imported from /Users/codehex/go/src/github.com/Code-Hex/hono-serve/node_modules/hono/dist/adapter/cloudflare-workers/server-static-module.js
    at new NodeError (node:internal/errors:405:5)
    at packageResolve (node:internal/modules/esm/resolve:782:9)
    at moduleResolve (node:internal/modules/esm/resolve:831:20)
    at defaultResolve (node:internal/modules/esm/resolve:1036:11)
    at DefaultModuleLoader.resolve (node:internal/modules/esm/loader:251:12)
    at DefaultModuleLoader.getModuleJob (node:internal/modules/esm/loader:140:32)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:33)
    at link (node:internal/modules/esm/module_job:75:36)

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '__STATIC_CONTENT_MANIFEST' imported from /Users/codehex/go/src/github.com/Code-Hex/hono-serve/node_modules/hono/dist/adapter/cloudflare-workers/server-static-module.js
    at new NodeError (node:internal/errors:405:5)
    at packageResolve (node:internal/modules/esm/resolve:782:9)
    at moduleResolve (node:internal/modules/esm/resolve:831:20)
    at defaultResolve (node:internal/modules/esm/resolve:1036:11)
    at DefaultModuleLoader.resolve (node:internal/modules/esm/loader:251:12)
    at DefaultModuleLoader.getModuleJob (node:internal/modules/esm/loader:140:32)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:33)
    at link (node:internal/modules/esm/module_job:75:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v20.5.1

@Code-Hex
Thank you! It is reproduced.
However, I didn't expect serveStatic to run on @hono/vite-dev-server. In the development phase, you can use the public directory to serve static files. Use serveStatic only in the build phase and running it with wrangler.
It's the same with Cloudflare Pages. You can refer to this template:
https://github.com/honojs/starter/tree/main/templates/cloudflare-pages
If you only build it, you won't face this issue.

@yusukebe Thank you for your reply.
The issue here arises from the fact that the __STATIC_CONTENT_MANIFEST included in hono gets bundled during package distribution, making it something that hono users cannot control during the build process.
As I mentioned in the linked comments, I am currently working on modifying the plugin mechanism to make it compatible with Wrangler as well. If you insist on your argument, then I will have no choice but to stop my work.

@Code-Hex
How about trying this, even though it might not be what you were expecting?
https://github.com/yusukebe/hono-serve/tree/use-public

@yusukebe While it might be acceptable for my specific use case, I believe it's a bit delicate to restrict users in how they can use it if we intend to release it as an official plugin.

@Code-Hex
Yes, ideally, we should support it. However, I think our current status is sufficient.
This is a matter of perspective. For the development phase, if we want fast reloading, we should use the public directory rather than a workers site. Vite can handle the public directory, but workers sites works in worked, which might be slower.
The reason I created the Vite plugin @hono/vite-dev-server is to use fast features like fast reloading or HMR (though it currently doesn't support SSR). Therefore, using the public directory for development makes sense to me.

@yusukebe Thanks.
I believe the main focus of this discussion, in my opinion, is whether it's feasible to achieve the preliminary stage before discussing speed.
First and foremost, it should be possible to reference the 'public' path (as specified in Wrangler) only in development mode. Perhaps we share the same understanding here.
The second point is that, in development, you cannot modify the behavior specific to Workers Site (such as __STATIC_CONTENT_MANIFEST). I've been mentioning this for a while now.
The reason for this is that hono is already bundling its own specific code.

Thanks for summarizing.
I've been considering the __STATIC_CONTENT_MANIFEST issue and have been thought whether we should include __STATIC_CONTENT_MANIFEST in Hono's code or make it a required option.
The popular library @cloudflare/kv-asset-handler, which is used for handling KV assets, treats __STATIC_CONTENT_MANIFEST as a required option.
import { getAssetFromKV, NotFoundError, MethodNotAllowedError } from '@cloudflare/kv-asset-handler'
import manifestJSON from '__STATIC_CONTENT_MANIFEST'
const assetManifest = JSON.parse(manifestJSON)

export default {
	async fetch(request, env, ctx) {
		if (request.url.includes('/docs')) {
			try {
				return await getAssetFromKV(
					{
						request,
						waitUntil(promise) {
							return ctx.waitUntil(promise)
						},
					},
					{
						ASSET_NAMESPACE: env.__STATIC_CONTENT,
						ASSET_MANIFEST: assetManifest,
					},
				)
			} catch (e) {
				if (e instanceof NotFoundError) {
					// ...
				} else if (e instanceof MethodNotAllowedError) {
					// ...
				} else {
					return new Response('An unexpected error occurred', { status: 500 })
				}
			}
		} else return fetch(request)
	},
}

So, I could follow this method, but I included '__STATIC_CONTENT_MANIFEST' directly in Hono's code because I prefer not to write an import statement for convenience. I'm not sure if this decision was good or bad, but in this situation, it became necessary to make it a required option.
Anyway, your PR https://github.com/honojs/hono/pull/1804 introduces a breaking change, so we can't merge it right now. If we do, it should be when releasing v4. I think the PR is good and we can include it in v4.

@yusukebe How about importing this line dynamically?
https://github.com/honojs/hono/blob/75dbd4dc229335d473b809b0f2190e3b4044b9bc/src/adapter/cloudflare-workers/server-static-module.ts#L5C23-L5C48

@yusukebe Great your idea!
I will try that on my local!

Resolve by #1984


New package: TraceMe v0.1.0

Registering package: TraceMe
Repository: https://github.com/bertschi/TraceFuns.jl
Created by: @bertschi
Version: v0.1.0
Commit: da502f7d4a71069f68e50c16834bf11324a869c3
Reviewed by: @bertschi
Reference: https://github.com/bertschi/TraceFuns.jl/commit/da502f7d4a71069f68e50c16834bf11324a869c3#commitcomment-82744413
Description: Simple function tracing for Julia

Presumably superseded by #67463


Why was the discussion removed?

What is your question?
...or it not deleted?

same question

?


Does it support syntax highlighting for Vue?

Maybe you are looking for this(https://github.com/vuejs/repl)?


FaF Support Request - Contact info

Changes in this PR

add contact info (step 2) page to the FaF form
allow DSI login within the FaF form

Screenshots of UI changes

 #234 FaF Support Request - Contact info


Feature/docs [WIP]

Add documentation for the package.
Can be found at: https://ingenjorsarbete-for-klimatet.github.io/smhi/

We could keep the name as smhi, but name the package ifk-smhi, i.e. loading and installing would use the ifk prefix but work here on github would just reference smhi, either works for me.

@docNord, updated some intro text, feel free to suggest changes and then we can merge this and update it in the other PRs for each client.

I think it looks really good. Two potential updates:
1 - a code snippet to show how to get a sample data set for each of the building blocks
2 - a link to https://ingenjorsarbeteforklimatet.se at the bottom of the documentation.

Fixed 2. I think we can add 1 to the docs from the individual PRs after we merge this. Would be nice to include the vectorised logo here, though.

@docNord logo in place, think this is good now.


markdown.smartSelect tests disabled

Disabled some markdown.smartSelect tests after seeing this failure
https://dev.azure.com/vscode/VSCode/_build/results?buildId=57510&view=logs&j=a5e52b91-c83f-5429-4a68-c246fc63a4f7&t=a83823bd-5dbd-5313-d0d6-a425f162cca0&l=680
I tried some markdown smart select scenarios and it seemed ok.

fixed


Track sim exists as a single instance, so multiple web users adjusting settings will be fighting each other's commands.

Fix: Each web session needs its own track instance, so the devices are simulated according to that sessions settings.

Created unique sessions for each web client with own instance of BOS and sims (branch: session_tracks). Still not functional for more than one client at this time, however, because each BOS/sim attempts to use the same ports - need to randomize ports for each instance.


[msal-node][msal-common] Cache Lookup 1: PR defining lookup interface

This PR moves around all cache code to a common folder cache and:

Adds look up interface
Adds Credential APIs to optimize entity based key generation
All current cache code is moved to spacache under cache folder. This will eventually go away as I submit more PRs on cache lookup

Changes ported to other PRs. Closing this.


Failed to initialize wrangler bindings proxy The Workers runtime failed to start

 ERROR  *** Received structured exception #0xc0000005: access violation; stack: 7ff9ed0e301f 7ff788f594eb 7ff788f595b3 7ff788f4d1ec 7ff788f4d197 7ff7887c832e 7ff7887c863f 7ff7876b1706 7ff7876b14ea 7ff78894047f 7ff788947636 7ff78894099c 7ff788947636 7ff78893e30c 7ff7876a1551 7ff789fdc8df 7ffa0e27257c 7ffa0eb4af27

 ERROR  Failed to initialize wrangler bindings proxy The Workers runtime failed to start. There is likely additional logging output above.

  at Miniflare2.#assembleAndUpdateConfig (node_modules\miniflare\src\index.ts:1343:10)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  at Mutex.runWith (node_modules\miniflare\src\workers\shared\sync.ts:66:45)
  at Miniflare2.#waitForReady (node_modules\miniflare\src\index.ts:1425:3)
  at Miniflare2._getProxyClient (node_modules\miniflare\src\index.ts:1631:3)
  at Miniflare2.getBindings (node_modules\miniflare\src\index.ts:1654:23)
  at async getPlatformProxy (node_modules\wrangler\wrangler-dist\cli.js:210786:20)
  at _getPlatformProxy (node_modules\nitro-cloudflare-dev\dist\runtime\plugin.dev.mjs:41:17)

https://github.com/cloudflare/workers-sdk/issues/4709
This just started happening.
"dependencies": {
  "@nuxtjs/critters": "^0.7.1",
  "@nuxtjs/device": "^3.1.1",
  "@nuxtjs/google-fonts": "^3.2.0",
  "@nuxtjs/seo": "^2.0.0-rc.15",
  "@nuxtjs/tailwindcss": "^6.12.1",
  "@splidejs/vue-splide": "^0.6.12",
  "nuxt-gtag": "^2.0.7",
  "tailwindcss": "^3.4.6",
  "tailwindcss-textshadow": "^2.1.3",
  "video.js": "^8.16.1",
  "videojs-youtube": "^3.0.1",
  "vue": "^3.4.31",
  "vue-router": "^4.4.0",
  "vue-tippy": "^6.4.4",
  "vue3-mq": "^3.2.0"
},
"devDependencies": {
  "@cloudflare/workers-types": "^4.20240712.0",
  "nitro-cloudflare-dev": "^0.1.5",
  "nuxt": "^3.12.3",
  "wrangler": "^3.65.0"
}

Can you try with wrangler 3.64.0 ?

It should be fixed in v0.1.6 (you can recreate your lock file).


Poor results for metal materials

Hi,
Thank you for this great work!
I tried IRON with my own datasets, when it came to metal materials, the results seems poor, do you know why?

sorry but I'm a bit confused. The example you show is not metallic?


Calculate for specific user

Is it possible to calculate the hours for each specific commit author? This is pretty useful when you end up with a shared branch that has multiple contributors.

Why was this closed?

@nhooyr It was a long time ago, but I think it's because it already breaks it down for you. I kind of made this issue without running it.


small shortcut issue

If you select either G28 or G30 in the Goto flyout tab and then try to reactivate jogging with Ctrl+Shift this is not possible. Closing the flyout tab does not help either.
If you enter G28 or G30 in the MDI the shortcut Ctrl+Shift works to activate jogging.

Missed that detail, will be fixed in next build (clicking on the Goto... buttons took away focus from the tab). In the next build the buttons will be disabled until the machine is homed as well. Ref. LinuxCNC docs:

Warning
Only use G28 when your machine is homed to a repeatable position and the desired G28 position has been stored with G28.1.


[cxx-interop][docs] Update the C++ stdlib module name

The C++ standard library module was renamed from std to CxxStdlib in the context of Swift.

@swift-ci please smoke test

@egorzhdan we should just import CxxStdlib in the docs - linux doesn't have submodules in libstdc++

Ah good point, I'll adjust that.

@swift-ci please smoke test


recursive definitions fail if recursive calls appear in the types of matchers

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Checked that your issue isn't already filed.
Reduced the issue to a self-contained, reproducible test case.

Description
In the following code (sorry, tried to make it even smaller, but couldn't), a "failed to prove
termination" error shows up in the definition of variable asdf, despite that the
statement proving well-foundedness of the call is directly above in hereIAm.
The error disappears when the line containing aaLtA is commented out,
or extracted to another function, which provides a workaround.
As probably a separate issue, when I try to inline asdf, Lean won't even notice
the variable hereIAm (it won't be shown among other defined variables in
the error description).
open Classical

def least (s: T → Prop) (nonempty: { t: T // s t }): T := sorry

structure WellOrder where
  T: Type
  lt: T → T → Prop
  wf: WellFounded lt

instance (w: WellOrder): WellFoundedRelation w.T where
  rel := w.lt
  wf := w.wf

namespace WellOrder
  @[reducible] def succ.lt (w: WellOrder): (a b: Option w.T) → Prop
    | none, _ => False
    | some _, none => True
    | some a, some b => w.lt a b

  def succ (w: WellOrder): WellOrder :=
    {
      T := Option w.T,
      lt := succ.lt w,
      wf := sorry
    }

  noncomputable def Morphism.initial.helper
    {wa wb: WellOrder}
    (aSucc: wa.succ.T)
    (fA: wa.T)
  :
    wb.T
  :=
    -- If I inline this, Lean won't even notice the variable
    -- `hereIAm` at all.
    let asdf (aa: { aa: wa.T // wa.succ.lt (some aa) aSucc }) :=
      let hereIAm: wa.succ.lt (some aa.val) aSucc := aa.property
      initial.helper (some aa)

    if hEq: some fA = aSucc then
      least
        (fun b =>
          ∀ aa: { aa: wa.T // wa.succ.lt (some aa) aSucc },
            (asdf aa) aa.val ≠ b)
        ⟨
          sorry,
          fun aa eq =>
            -- If the next line is commented out, or extracted
            -- to a separate function, the error disappears.
            let aaLtA: wa.lt aa fA := hEq.symm ▸ aa.property
            sorry
        ⟩
      else sorry
    termination_by initial.helper a fA => a
end WellOrder

Steps to Reproduce

Paste the above code to VS Code.

Expected behavior: Termination is proven.
Actual behavior: An error shows up.
Reproduces how often: Always.
Versions
Both Lean 4 stable and nightly
Lean (version 4.0.0-nightly-2022-09-14, commit fccb60fb69be, Release),
Lean (version 4.0.0, commit 7dbfaf9b7519, Release)
Ubuntu 22.04.1 LTS

In the following code (sorry, tried to make it even smaller, but couldn't), a "failed to prove
termination" error shows up in the definition of variable asdf, despite that the
statement proving well-foundedness of the call is directly above in hereIAm.

I see this goal:
failed to prove termination, possible solutions:
  - Use `have`-expressions to prove the remaining goals
  - Use `termination_by` to specify a different well-founded relation
  - Use `decreasing_by` to specify your own tactic for discharging this kind of goal
wawb: WellOrder
aSucc✝: wa.succ.T
fA✝: wa.T
a✝: (y : (_ : wa.succ.T) ×' wa.T) →
  (invImage (fun x => PSigma.casesOn x fun aSucc fA => aSucc) (instWellFoundedRelationT wa.succ)).1 y ⟨aSucc✝, fA✝⟩ →
    wb.T
asdf: { aa // wa.succ.lt (some aa) aSucc✝ } → wa.T → wb.T := fun aa =>
  let hereIAm := ⋯;
  fun fA => a✝ ⟨some aa.val, fA⟩ ⋯
hEq: some fA✝ = aSucc✝
aa✝: { aa // wa.succ.lt (some aa) aSucc✝ }
eq: asdf aa✝ aa✝.val = sorryAx wb.T
h✝¹: some fA✝ = aSucc✝
h✝: wa.succ.lt (some aa✝.val) aSucc✝
aSucc: wa.succ.T
aa: { aa // wa.succ.lt (some aa) aSucc }
hereIAm: wa.succ.lt (some aa.val) aSucc := aa.property
fA: wa.T
⊢ wa.succ.lt (some aa.val) aSucc✝

Note that the goal wants aSucc✝, which is shadowed by aSucc, and hereIAm is about aSucc not aSucc✝. I have not idea why the let below would introduce a new aSucc binding here.

Thanks for minimizing. Writing
def bar (n: Nat): True :=
  match n with
  | Nat.zero => trivial

  | Nat.succ nPred =>
    let asdf: foo (bar nPred) := trivial
    -- Commenting out the next line hides the issue.
    let ⟨⟩ := asdf
    trivial
decreasing_by done

I see two goals, namely
unsolved goals
nPred: Nat
x✝: ∀ (y : Nat), (invImage (fun x => x) instWellFoundedRelationOfSizeOf).1 y nPred.succ → True
⊢ (invImage (fun x => x) instWellFoundedRelationOfSizeOf).1 nPred nPred.succ

nPred: Nat
x✝: ∀ (y : Nat), (invImage (fun x => x) instWellFoundedRelationOfSizeOf).1 y nPred.succ → True
asdf: foo (x✝ nPred ?m.202) := trivial
n: Nat
⊢ (invImage (fun x => x) instWellFoundedRelationOfSizeOf).1 n nPred.succ

The first one seems to corresponds to the type of the let binding, and is fine (nPred is mentioned).
The second one comes from
match asdf with | True.intro => trivial

which, if we disable pp.match, reads like this
bar.match_1 bar nPred (fun (asdf : foo (bar nPred)) => True) asdf fun (_ : Unit) => trivial

with
bar.match_1 : ∀ (bar : Nat → True) (nPred : Nat) (motive : foo (bar nPred) → Prop) (asdf : foo (bar nPred)),
  (Unit → motive True.intro) → motive asdf

and after the translation we get
          bar.match_1
            (fun (n : Nat) =>
              x n
                (sorryAx
                  ((@invImage Nat Nat (fun (x : Nat) => x) (@instWellFoundedRelationOfSizeOf Nat instSizeOfNat)).1 n
                    nPred.succ)
                  true))
            nPred
            (fun
                (asdf :
                  foo
                    (x nPred
                      (sorryAx
                        ((@invImage Nat Nat (fun (x : Nat) => x) (@instWellFoundedRelationOfSizeOf Nat instSizeOfNat)).1
                          nPred nPred.succ)
                        true))) =>
              True)
            asdf fun (_ : Unit) => trivial)

where the sorryAx comes from the failing decreasing_by done.
So the problem is that the match construction yielding to bar.match_1 abstracts the free variables, including bar, it seems. This means we have an unsaturated call to bar, and there is no chance to proof that terminating.
If the matcher would abstract over bar_nPred together and have the type
bar.match_1 : ∀ (bar_nPred : True) (motive : foo bar_nPred → Prop) (asdf : foo bar_nPred),
  (Unit → motive True.intro) → motive asdf

then things would be well. Alternatively, we could try to unfold the matcher in this construction, although that is likely to blow up the proof term size.
The code to improve to abstract over each applications of free variables separately would be in Lean.Meta.Closure.mkValueTypeClosure.
A work-around is to let-bind the recursive call, on its own, yourself:
def bar (n: Nat): True :=
  match n with
  | Nat.zero => trivial
  | Nat.succ nPred =>
    let bar_nPred := bar nPred
    let asdf: foo bar_nPred := trivial
    let ⟨⟩ := asdf
    trivial

Given that the work-around exists, and it may be hard to fix, maybe not too pressing.

Just for reference, I found another small piece of code that might be worth looking into if someone ever decides to dedicate their time to this. This time, there isn't any recursion involved at all.
structure Asdf where
  T: Type
  t: T

def foo (asdf: Asdf) :=
  let ⟨T, _⟩ := asdf

  let a: asdf.T := asdf.t
  let b: T := asdf.t

  42

It seems that extracting a member of a structure with ⟨⟩ and a member access operator,
though it naively ought to be the same, are quite different operations.
The error:
type mismatch
  asdf.t
has type
  asdf.T : Type
but is expected to have type
  T : Type

I think this is unrelated, and probably an instances of the issue described in https://github.com/leanprover/lean4/issues/5216


Backport build_torcx_store manifest changes

This backports https://github.com/coreos/scripts/pull/737
We'll want to pull in https://github.com/euank/scripts/commit/e858e727b05668da98ebb74878c298097cf2a03b once this branch goes to beta as well.

I manually gave ./build_torcx_store --upload a run and it seemed to work.
Since we aren't using casync any more, there isn't any need for overlay / portage changes.

Shouldn't it still build 17.06 when it goes to beta?  We don't want it as an option?

@dm0- the tectonic-torcx thing only really needs 1.12, but if we want to toss 17.06 in EXTRA_IMAGES I wouldn't say no. It just won't immediately be used other than in testing.


@ConditionalOnProperty target property with no metadata

Several auto-configurations use a condition on a property that has no metadata. As a result, trying to use it to customize the auto-configuration lead to a warning in an IDE.
The report detected the following:
org.springframework.cloud.gcp.autoconfigure.logging.StackdriverLoggingAutoConfiguration [spring.cloud.gcp.logging.enabled]
org.springframework.cloud.gcp.autoconfigure.pubsub.GcpPubSubAutoConfiguration [spring.cloud.gcp.pubsub.enabled]
org.springframework.cloud.gcp.autoconfigure.sql.GcpCloudSqlAutoConfiguration [spring.cloud.gcp.sql.enabled]
org.springframework.cloud.gcp.autoconfigure.trace.StackdriverTraceAutoConfiguration [spring.cloud.gcp.trace.enabled]

The mentioned configuration properties just don't have a particular @ConfigurationProperties class representative.
@snicoll ,
any ideas what would you like to see as a fix?
Thanks

Thanks for the feedback.

any ideas what would you like to see as a fix?

Yes, that's what manual metadata is for. When a property is not used by the code directly, it doesn't make much sense to fake a property by adding it to the model. For those cases, we can document the keys manually.

Thanks, @snicoll , for the right direction!
Any pointers how to test or at least reproduce?
Is it just a content assistance issue in the IDE?

I can't provide you with a way to test it doesn't happen again I am afraid as this is some code from Jetbrains scanning the code and spotting those mistakes (See also https://youtrack.jetbrains.com/issue/IDEA-197990).

Is it just a content assistance issue in the IDE?

Like any other property the project may define, yes.


Broken docker pull from public.ecr.aws

Is this team responsible for pushing images up to public.ecr.aws?
If so…
docker pull public.ecr.aws/lambda/provided:al2023

With the response:
Error response from daemon: failed to resolve reference "public.ecr.aws/lambda/provided:al2023": unexpected status from HEAD request to https://public.ecr.aws/v2/lambda/provided/manifests/al2023: 403 Forbidden

Anyone else seeing this? I don't have anything for public.ecr.aws in my ~/.docker/config file.

Hello @skyzyx! Thinking here that maybe you may have some blocks on your network or was this a temporary error? I managed to pull the image just now.
Can you please try again?
docker pull public.ecr.aws/lambda/provided:al2023
al2023: Pulling from lambda/provided
569cc7a04d3d: Pull complete
9d72fb16d46c: Pull complete
60d60f0796ad: Pull complete
0943ac8b622e: Pull complete
Digest: sha256:1bcfd1c03e1eca6357e55042c34d4ac5ab61e6786e2015ef57030036f03d9b96
Status: Downloaded newer image for public.ecr.aws/lambda/provided:al2023
public.ecr.aws/lambda/provided:al2023

It's been happening for about a week. Just tried it again and got the same error.
Did you try from inside the Amazon network, or outside the Amazon network?

Both network and worked! Did you log into ECR Public by any chance? Did you try docker logout public.ecr.aws and try pulling again?

That was it. Weird. I didn't know that you could even login to public.ecr.aws or when I would have done it.
Thanks!

That was it. Weird. I didn't know that you could even login to public.ecr.aws or when I would have done it.
Thanks!

Wow cool! It could be some script or something else that left an invalid/expired public ecr credential in your environment and then running the logout command cleared it.


Stocksnap now requires a User-Agent header

Description

After applying the fix described in #758 locally, I tried running the DAG but I was met with the following error:
[2022-10-01, 00:10:50 UTC] {factory_utils.py:135} INFO - Beginning ingestion
[2022-10-01, 00:10:50 UTC] {provider_data_ingester.py:151} INFO - Begin ingestion for StockSnapDataIngester
[2022-10-01, 00:10:50 UTC] {requester.py:69} WARNING - Unable to request URL: https://stocksnap.io/api/load-photos/date/desc/1.  Status code: 403
[2022-10-01, 00:10:50 UTC] {requester.py:115} WARNING - Bad response_json:  None
[2022-10-01, 00:10:50 UTC] {requester.py:116} WARNING - Retrying:
_get_response_json(
    https://stocksnap.io/api/load-photos/date/desc/1,
    {},
    retries=2)
[2022-10-01, 00:10:51 UTC] {requester.py:69} WARNING - Unable to request URL: https://stocksnap.io/api/load-photos/date/desc/1.  Status code: 403
[2022-10-01, 00:10:51 UTC] {requester.py:115} WARNING - Bad response_json:  None
[2022-10-01, 00:10:51 UTC] {requester.py:116} WARNING - Retrying:
_get_response_json(
    https://stocksnap.io/api/load-photos/date/desc/1,
    {},
    retries=1)
[2022-10-01, 00:10:52 UTC] {requester.py:69} WARNING - Unable to request URL: https://stocksnap.io/api/load-photos/date/desc/1.  Status code: 403
[2022-10-01, 00:10:52 UTC] {requester.py:115} WARNING - Bad response_json:  None
[2022-10-01, 00:10:52 UTC] {requester.py:116} WARNING - Retrying:
_get_response_json(
    https://stocksnap.io/api/load-photos/date/desc/1,
    {},
    retries=0)
[2022-10-01, 00:10:53 UTC] {requester.py:69} WARNING - Unable to request URL: https://stocksnap.io/api/load-photos/date/desc/1.  Status code: 403
[2022-10-01, 00:10:53 UTC] {requester.py:115} WARNING - Bad response_json:  None
[2022-10-01, 00:10:53 UTC] {requester.py:116} WARNING - Retrying:
_get_response_json(
    https://stocksnap.io/api/load-photos/date/desc/1,
    {},
    retries=-1)
[2022-10-01, 00:10:53 UTC] {requester.py:101} ERROR - No retries remaining.  Failure.
[2022-10-01, 00:10:53 UTC] {provider_data_ingester.py:396} INFO - Committed 0 records
[2022-10-01, 00:10:53 UTC] {taskinstance.py:1851} ERROR - Task failed with exception
providers.provider_api_scripts.provider_data_ingester.IngestionError: Retries exceeded
query_params: {}

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/operators/python.py", line 175, in execute
    return_value = self.execute_callable()
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/operators/python.py", line 193, in execute_callable
    return self.python_callable(*self.op_args, **self.op_kwargs)
  File "/usr/local/airflow/openverse_catalog/dags/providers/factory_utils.py", line 140, in pull_media_wrapper
    data = run_func(*args)
  File "/usr/local/airflow/openverse_catalog/dags/providers/provider_api_scripts/provider_data_ingester.py", line 194, in ingest_records
    raise error from ingestion_error
  File "/usr/local/airflow/openverse_catalog/dags/providers/provider_api_scripts/provider_data_ingester.py", line 161, in ingest_records
    batch, should_continue = self.get_batch(query_params)
  File "/usr/local/airflow/openverse_catalog/dags/providers/provider_api_scripts/provider_data_ingester.py", line 295, in get_batch
    response_json = self.get_response_json(query_params)
  File "/usr/local/airflow/openverse_catalog/dags/providers/provider_api_scripts/provider_data_ingester.py", line 314, in get_response_json
    return self.delayed_requester.get_response_json(
  File "/usr/local/airflow/openverse_catalog/dags/common/requester.py", line 123, in get_response_json
    response_json = self.get_response_json(
  File "/usr/local/airflow/openverse_catalog/dags/common/requester.py", line 123, in get_response_json
    response_json = self.get_response_json(
  File "/usr/local/airflow/openverse_catalog/dags/common/requester.py", line 123, in get_response_json
    response_json = self.get_response_json(
  [Previous line repeated 1 more time]
  File "/usr/local/airflow/openverse_catalog/dags/common/requester.py", line 102, in get_response_json
    raise RetriesExceeded("Retries exceeded")
common.requester.RetriesExceeded: Retries exceeded

I added a faux User-Agent to the headers and was able to get past that step, but then also got these logs:
[2022-10-01, 00:17:48 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/AMEYDHBGJF.jpg.  Status code: 403
[2022-10-01, 00:17:49 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/XGMAQNG7PY.jpg.  Status code: 403
[2022-10-01, 00:17:50 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/KGCLUBUAEW.jpg.  Status code: 403
[2022-10-01, 00:17:51 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/G4YYZSAXAT.jpg.  Status code: 403
[2022-10-01, 00:17:52 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/REBSHVJHFH.jpg.  Status code: 403
[2022-10-01, 00:17:53 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/THGALOFGEU.jpg.  Status code: 403
[2022-10-01, 00:17:54 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/L98SVEZOVY.jpg.  Status code: 403
[2022-10-01, 00:17:55 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/48WQRY7ULS.jpg.  Status code: 403
[2022-10-01, 00:17:56 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/P3VSWDGHSQ.jpg.  Status code: 403
[2022-10-01, 00:17:57 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/8BQCLWJLDK.jpg.  Status code: 403
[2022-10-01, 00:17:58 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/THV0XGK4LP.jpg.  Status code: 403
[2022-10-01, 00:17:59 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/MF8LSXR049.jpg.  Status code: 403
[2022-10-01, 00:18:00 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/9KUQONMKX7.jpg.  Status code: 403
[2022-10-01, 00:18:01 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/IJAX71RJBA.jpg.  Status code: 403
[2022-10-01, 00:18:02 UTC] {requester.py:69} WARNING - Unable to request URL: https://cdn.stocksnap.io/img-thumbs/960w/S9DODB5OXH.jpg.  Status code: 403
...

I believe that this is the result of the request in _get_filesize:
https://github.com/WordPress/openverse-catalog/blob/d828d257adc70121d0b2d8b926e3d625f700651c/openverse_catalog/dags/providers/provider_api_scripts/stocksnap.py#L157
Note that this relates to #631, perhaps we should pass the ProviderDataIngester::headers attribute into the DelayedRequester at initialization time so all requests made within a class's DelayedRequester can use the default headers?
Reproduction

Apply the patch described in #758
Run the Stocksnap DAG
Add a User-Agent to the headers dict here
Run the DAG again

Resolution

[ ] 🙋 I would be interested in resolving this bug.

See also:
[ins] In [1]: import requests

[ins] In [2]: r = requests.get("https://stocksnap.io/api/load-photos/date/desc/1")

[ins] In [3]: r
Out[3]: <Response [403]>

[ins] In [4]: r = requests.get("https://stocksnap.io/api/load-photos/date/desc/1", headers={"User-Agent": "madison-test-
         ...: bot"})

[ins] In [5]: r
Out[5]: <Response [200]>

Some example code for how to approach this can be found in the Wikimedia script:
https://github.com/WordPress/openverse-catalog/blob/18decf9b70f409bc83809d14b7be3b65cb91d409/openverse_catalog/dags/providers/provider_api_scripts/wikimedia_commons.py#L50


Linux 5.7 and DB845c alsa patches.

Targets dunfell too.

@ndechesne The premerge builds ok in db845c, For some reason the rpb build on db410c  was aborted.

run tests

run tests.

run tests, one more time!


https://youtu.be/MnH-TCblLGo?si=MHgJWpXP-f7fHBq_

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

Pre-requisites

[X] My application to the GitHub Technology Partner Program is approved.

Tasks

[X] MUST follow our general contributing guidelines for voice and markup format.
[X] MUST emphasize how the third-party product works with GitHub.
[X] MUST be written in Markdown format, using one of the templates provided.
[X] MUST include the name and URL of the GitHub technology partner responsible for maintenance of the documentation being contributed. This should be added via the contributor.name and contributor.URL properties in the template's YAML frontmatter.
[X] MUST be proposed via a pull request to this repo following the GitHub Flow.
[X] MUST be located in the root of the content folder. Your filename MUST match the GitHub technology partner name, and use the .md file extension.

Pull Request

[X] MUST reference this issue, e.g. via closes [this issue number].
[X] MUST pass the automated CI checks.
[X] MUST include links to supporting material demonstrating the functionality being documented (this can be a link to a public GitHub repo, or a video / screencast walkthrough).

https://youtu.be/-mfladpK0AA?si=OkX9C9SuHuGB-U2L


opt simplify decimalv3 comparison predicate

Proposed changes
Issue Number: close #xxx

fix constant folding failed on decimalv3 type
support reduce decimalv3 literal precision in comparison predicate
support fe config enable_decimal_conversion

Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.19 seconds
stream load tsv:          428 seconds loaded<PHONE_NUMBER>9 Bytes, about 166 MB/s
stream load json:         23 seconds loaded<PHONE_NUMBER> Bytes, about 97 MB/s
stream load orc:          59 seconds loaded<PHONE_NUMBER> Bytes, about 17 MB/s
stream load parquet:          30 seconds loaded 861443392 Bytes, about 27 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230423135148_clickbench_pr_133489.html

run buildall

run buildall

run buildall


Enhance:Elaborate Emotional Health, Social Well-being, and Spiritual Wellness Sections

Enhance the user experience and provide comprehensive information by elaborating on the sections related to Emotional Health, Social Well-being, and Spiritual Wellness when users click on these sections. This modification aims to offer users a more in-depth understanding of these aspects of well-being.

Identify the sections related to Emotional Health, Social Well-being, and Spiritual Wellness on the website.
Implement JavaScript functionality to handle click events on these sections.
Create dedicated pages or expand existing sections to provide detailed information on Emotional Health, Social Well-being, and Spiritual Wellness.
Ensure the content is informative, engaging, and aligned with the overall website design.

Problems:

Limited Information:

Users may find limited information on Emotional Health, Social Well-being, and Spiritual Wellness, hindering their understanding of these aspects.

Solution:

Elaborating on these sections upon user interaction provides users with valuable insights, promoting a holistic approach to well-being.

Steps to Reproduce:

Navigate to the sections related to Emotional Health, Social Well-being, and Spiritual Wellness.
Observe the lack of detailed information or dedicated content within these sections.
After the issue is resolved, click on these sections and verify that they now provide comprehensive information.

@ritika728 assign this issue to me tomorrow after noon under JWOC.

@ritika728, as I am commenting after the coding period has begun. Please assign this to me under JWOC

@ritika728, as I am commenting after the coding period has begun. Please assign this to me under JWOC

I also commented after coding period .

@ritika728 thank u so much, i will update you if any help needed.


State accounts don't work with InstructionFormatter.format

Devs PLZ FIX!!!

Please explain what is not working with an example.

Please explain what is not working with an example.