Circular dependencies in $houdini folder

Describe the bug
Generated $houdini folder has some circular dependencies across *.js files. It may lead to unpredictable consequences, including vite hangs.
It is reproducible in the example-sveltekit-todo project. The minimal reproduction repo I provide is an example-sveltekit-todo fork, with updated houdini and added vite-plugin-circular-dependency to simplify the search of circular dependencies.
Found circular dependencies are:
  $houdini/runtime/cache/cache.js
  	$houdini/runtime/cache/cache.js -> $houdini/runtime/cache/lists.js
  	$houdini/runtime/cache/cache.js -> $houdini/runtime/cache/subscription.js

  $houdini/index.js
  	$houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/stores/mutation.js -> $houdini/plugins/houdini-svelte/stores/AddItem.js -> $houdini/plugins/houdini-svelte/stores/index.js -> src/client.ts
  	$houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js -> $houdini/plugins/houdini-svelte/stores/AllItems.js -> $houdini/plugins/houdini-svelte/stores/index.js -> src/client.ts
  	$houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js -> src/client.ts
  	$houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js -> src/client.ts

First two are absolutely valid (verified manually), tho I'm not 100% sure about the rest: it is quite hard to go through many of export * from 'foo'.
Reproduction
https://github.com/shadow-identity/example-sveltekit-todo

Thanks for reporting these. If you have the time/energy to give it a shot i'd gladly offer any assistance you need.

This is causing regular issues with my project - vite starts fine, but any hot reload has a chance of crashing vite with a circular dependency error in SSR, even when working on pages with no houdini interactions.

10:17:02 PM [vite] page reload $houdini/runtime/index.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/fragments.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/index.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/session.js
10:17:02 PM [vite] page reload $houdini/runtime/client/index.js
10:17:02 PM [vite] page reload $houdini/runtime/client/documentStore.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/config.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/flatten.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/deepEquals.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/index.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/lru.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/log.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/key.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/pageInfo.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/pagination.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/scalars.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/selection.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/store.js
10:17:02 PM [vite] page reload $houdini/runtime/lib/types.js
10:17:02 PM [vite] page reload $houdini/runtime/public/cache.js
10:17:02 PM [vite] page reload $houdini/runtime/public/index.js
10:17:02 PM [vite] page reload $houdini/runtime/public/record.js
10:17:02 PM [vite] page reload $houdini/runtime/public/list.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/gc.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/cache.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/index.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/lists.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/staleManager.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/stuff.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/subscription.js
10:17:02 PM [vite] page reload $houdini/runtime/cache/storage.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/base.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/index.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/mutation.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/query.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/subscription.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/fragment.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/cache.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/fetch.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/fetchParams.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/fragment.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/mutation.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/index.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/query.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/optimisticKeys.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/subscription.js
10:17:02 PM [vite] page reload $houdini/runtime/client/plugins/throwOnError.js
10:17:02 PM [vite] page reload $houdini/runtime/client/utils/documentPlugins.js
10:17:02 PM [vite] page reload $houdini/runtime/client/utils/index.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js
10:17:02 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/types.js
10:17:02 PM [vite] page reload $houdini/runtime/router/types.js
10:17:02 PM [vite] page reload $houdini/runtime/index.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/fragments.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/index.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/session.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/cache.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/gc.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/index.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/storage.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/stuff.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/staleManager.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/lists.js
10:17:03 PM [vite] page reload $houdini/runtime/cache/subscription.js
10:17:03 PM [vite] page reload $houdini/runtime/client/documentStore.js
10:17:03 PM [vite] page reload $houdini/runtime/client/index.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/config.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/deepEquals.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/flatten.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/key.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/log.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/lru.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/pageInfo.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/index.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/scalars.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/pagination.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/store.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/types.js
10:17:03 PM [vite] page reload $houdini/runtime/public/cache.js
10:17:03 PM [vite] page reload $houdini/runtime/public/index.js
10:17:03 PM [vite] page reload $houdini/runtime/lib/selection.js
10:17:03 PM [vite] page reload $houdini/runtime/public/record.js
10:17:03 PM [vite] page reload $houdini/runtime/public/list.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/base.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/fragment.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/mutation.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/index.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/query.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/subscription.js
10:17:03 PM [vite] page reload $houdini/runtime/client/utils/documentPlugins.js
10:17:03 PM [vite] page reload $houdini/runtime/client/utils/index.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/cache.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/fragment.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/fetch.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/index.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/fetchParams.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/mutation.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/optimisticKeys.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/query.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/subscription.js
10:17:03 PM [vite] page reload $houdini/runtime/client/plugins/throwOnError.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js
10:17:03 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/types.js
10:17:03 PM [vite] page reload $houdini/runtime/router/types.js
10:18:21 PM [vite] page reload src/routes/api/acuity/webhook/+server.ts
10:18:22 PM [vite] page reload $houdini/runtime/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/fragments.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/session.js
10:18:22 PM [vite] page reload $houdini/runtime/client/index.js
10:18:22 PM [vite] page reload $houdini/runtime/client/documentStore.js
10:18:22 PM [vite] page reload $houdini/runtime/public/cache.js
10:18:22 PM [vite] page reload $houdini/runtime/public/index.js
10:18:22 PM [vite] page reload $houdini/runtime/public/list.js
10:18:22 PM [vite] page reload $houdini/runtime/public/record.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/config.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/deepEquals.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/flatten.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/index.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/lru.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/log.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/pageInfo.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/scalars.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/pagination.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/selection.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/store.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/types.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/cache.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/index.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/gc.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/lists.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/stuff.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/storage.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/base.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/staleManager.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/subscription.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/fragment.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/mutation.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/query.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/subscription.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/key.js
10:18:22 PM [vite] page reload $houdini/runtime/client/utils/documentPlugins.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/cache.js
10:18:22 PM [vite] page reload $houdini/runtime/client/utils/index.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/fetch.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/fetchParams.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/fragment.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/index.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/mutation.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/query.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/optimisticKeys.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/subscription.js
10:18:22 PM [vite] page reload $houdini/runtime/client/plugins/throwOnError.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/types.js
10:18:22 PM [vite] page reload $houdini/runtime/router/types.js
10:18:22 PM [vite] page reload $houdini/runtime/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/fragments.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/index.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/cache.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/gc.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/index.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/lists.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/staleManager.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/stuff.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/storage.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/session.js
10:18:22 PM [vite] page reload $houdini/runtime/client/documentStore.js
10:18:22 PM [vite] page reload $houdini/runtime/client/index.js
10:18:22 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/types.js
10:18:22 PM [vite] page reload $houdini/runtime/cache/subscription.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/config.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/deepEquals.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/flatten.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/index.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/key.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/log.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/lru.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/pageInfo.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/pagination.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/scalars.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/selection.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/store.js
10:18:22 PM [vite] page reload $houdini/runtime/lib/types.js
10:18:22 PM [vite] page reload $houdini/runtime/public/cache.js
10:18:22 PM [vite] page reload $houdini/runtime/public/index.js
10:18:22 PM [vite] page reload $houdini/runtime/public/record.js
10:18:22 PM [vite] page reload $houdini/runtime/public/list.js
10:18:23 PM [vite] page reload $houdini/runtime/router/types.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/base.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/fragment.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/index.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/mutation.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/query.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/subscription.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/cache.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/fetch.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/fetchParams.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/fragment.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/index.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/mutation.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/optimisticKeys.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/query.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/subscription.js
10:18:23 PM [vite] page reload $houdini/runtime/client/utils/documentPlugins.js
10:18:23 PM [vite] page reload $houdini/runtime/client/utils/index.js
10:18:23 PM [vite] page reload $houdini/runtime/client/plugins/throwOnError.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js
10:18:23 PM [vite] page reload $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js
10:18:23 PM [vite] Error when evaluating SSR module /$houdini/runtime/cache/lists.js: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /$houdini/runtime/cache/cache.js: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /$houdini/runtime/cache/index.js: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /$houdini/runtime/client/index.js: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /$houdini/index.js: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /src/hooks.server.ts: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

10:18:23 PM [vite] Error when evaluating SSR module /src/routes/+layout.ts: failed to import "/$houdini/runtime/cache/cache.js"
|- Error: [vite] The dependency module is not yet fully initialized due to circular dependency. This is a bug in Vite SSR
    at ssrImport (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52599:19)
    at eval (/Users/francis/project/$houdini/runtime/cache/lists.js:4:37)
    at async instantiateModule (file:///Users/francis/project/node_modules/vite/dist/node/chunks/dep-mCdpKltl.js:52650:5)

@fnimick looking through your logs, i think the culprit is that first cycle that @shadow-identity called out. I pushed up a branch that removes it - mind seeing if that was enough to fix your issue? The branch name is circular-imports

Gonna 👀  this. I'm seeing similar behavior on latest version (1.2.54).
✖ Found 4 circular dependencies!

1) $houdini/runtime/cache/cache.js > $houdini/runtime/cache/lists.js
2) $houdini/runtime/cache/cache.js > $houdini/runtime/cache/subscription.js
3) $houdini/runtime/cache/cache.d.ts > $houdini/runtime/cache/subscription.d.ts
4) .svelte-kit/output/server/chunks/query.js > .svelte-kit/output/server/chunks/client.js```

<img width="743" alt="Screenshot 2024-08-15 at 9 54 05 AM" src="https://github.com/user-attachments/assets/6e742683-0337-44f2-b8ef-5252e837a371">

that circle should be fixed in the branch. Let me open a PR with just that fix

The first two error messages don't appear anymore, but the last four (from  $houdini/index.js) are still here. I updated the reproduction repository with the updated houdini and houdini-svelte dependencies.
Should we reopen the ticket or create a new one?
  $houdini/index.js
        $houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/stores/mutation.js -> $houdini/plugins/houdini-svelte/stores/AddItem.js -> $houdini/plugins/houdini-svelte/stores/index.js -> src/client.ts
        $houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js -> $houdini/plugins/houdini-svelte/stores/AllItems.js -> $houdini/plugins/houdini-svelte/stores/index.js -> src/client.ts
        $houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/fragment.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js -> src/client.ts
        $houdini/index.js -> $houdini/plugins/houdini-svelte/runtime/client.js -> $houdini/plugins/houdini-svelte/runtime/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/index.js -> $houdini/plugins/houdini-svelte/runtime/stores/pagination/query.js -> src/client.ts

For some reason, even without updating houdini, I haven't run into circular imports in a while. Unfortunately I am not able to reliably duplicate the issue - it tends to happen after my dev server has been running and doing hot reloads and rebuilds for hours.

Thanks for the update @fnimick. I'm gonna leave this issue open to address them anyway, just to be sure.


Request for information: configuration to format a markdown document on a console

How can flexmark be configured to format a markdown document on a console?
I am using the spring shell library on a client application which must display help on the console which is formatted in markdown. I would like this help to be displayed in a formatted text form. How can I do this? Is there an extension I could use to get this rendering.

This isn't a responsibility of flexmark-java. It's up to the developer who wants to use the library to make a program tailored to their particular requirements.
My text editor, KeenWrite, uses flexmark-java both when running from the command-line and from running through the user interface.
Broadly:

Write a Java program that has a main(String args[]).
Open a file from the given arguments, or open standard input.
Read from the stream.
Create a newly configured instance of flexmark-java's parser.
Pass the stream to the parser.
Write the transformed document to standard output (or a file if given on the command-line).

How you implement this is your responsibility, flexmark-java will only do the heavy lifting of transforming the document.

@jlerbsc if this answers your question, please close the ticket. You may wish to ask specific questions about integration on StackOverflow.
Otherwise, please add more details about your question.


Add stackbit.config.ts

- Summary

- Test plan

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

👷 Deploy Preview for starfri processing.

Name
Link

🔨 Latest commit
43b99cdca5828f8bb4db0033b221c4427bb29587

🔍 Latest deploy log
https://app.netlify.com/sites/starfri/deploys/66d59f6c42e5a7000821d0e6


Docker compose

Codecov Report

Merging #24 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #24   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          10     10
  Lines         255    255
  Branches        9      9
=====================================
  Hits          255    255

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d41bea...25bfcc7. Read the comment docs.


Dependencies

There seem to be lots of dependencies in addition to your installation instructions, all need to be installed into the environment. The instructions are not clear that the CSD Python API needs to be installed into the environment (not included in the command line text). I am on Windows 7, which I know is suboptimal, but I have got stuck with the requirement for sklearn.  I do get the warning
WARNING conda.core.prefix_data:_load_single_record(167): Ignoring malformed pref
ix record at: C:\Anaconda\conda-meta\csd-python-api-2.0.0-win32-64-py2.7-conda.j
son
I think I have installed sklearn into the virtual environment, if I try to reinstall it says it is already there, but the hotspot installation does not find the dependency.
Beth

Managed to fix that by using pip install rather than conda install.
Now I have the following error for the Hotspot installation, I have no ideas what this means.
Command "C:\Anaconda\envs\hotspots_env\python.exe -u -c "import setuptools, toke
nize;file='c:\users\beth~1.tho\appdata\local\temp\pip-build-7x9pzn\cy
thon\setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().re
place('\r\n', '\n'), file, 'exec'))" install --record c:\users\beth~1.tho\ap
pdata\local\temp\pip-rqc2xn-record\install-record.txt --single-version-externall
y-managed --compile" failed with error code 1 in c:\users\beth~1.tho\appdata\loc
al\temp\pip-build-7x9pzn\cython\

Hi @BThomasStorm ,
@pslacerda has updated the installation instructions. Please could you try a fresh installation and let us know if you are successful?
Thanks,
Pete

@BThomasStorm, probably it will work on Windows. Anaconda does a great job resolving dependencies everywhere. I don't know about the CSD Python API conda package but maybe it will also work on Windows.
If I'm not mistaken, Ghecom is Linux only, so if asked you may choose LIGSITE instead, is a notable difference between platforms. Probably it will be automatic.
@prcurran, the badges were nice, I'll try to recover them soon. Just let me know what JavaScript coding are you checking the quality?? Anyway, 100% of 0LOC LGTM!

@pslacerda @BThomasStorm, Ghecom only runs on Linux, you are correct. However, LIGSITE can be run on all OS and therefore this option can be selected by users. I should really put some restriction of the options you can choose based on the detected operating system (i'll put it on the TODO list). I will also put a task to update the requirments.txt / setup.py so that these dependencies are install automatically with hotspots package.
@pslacerda the badges are super easy to replicate! The JS code is for the documentation, kind of cheating since it's auto-generated using sphinx but nevermind!
Thank-you both for your contributions :)

Cool, so you added the RDKit channel. I found the conda package for CSD Python API inside my CSD_HOME. I'll try to do pull a docs update tomorrow.

Thanks both for your input.
I have updated the readme.md:

there is a link to the CSD Python API standalone installer (there is a conda channel coming soon for this)
I've moved all the dependencies into the setup.py
I have found that if you activate your conda environment, then pip install the hotspots-v1.0.0.zip that the requirements are installed automatically.

Action: check required versions


Different message id for same message for different user

I have two different clients for two different users  that subscribed to the same group.
When i get messages (GetChatHistory) for each user  i see that same message for each user come with different 'id'.
if I have some way to understand that this is the same message or maybe to make something that the messages were returned with the same id?

This is an expected behavior. Message id will be the same only in supergroups (and channels). There is no way to surely match the same message for different users.

۱۳۹۸-۰۲-۱۰ ۰:۳۲ +۰۴:۳۰ گرینویچ, Aliaksei Levin<EMAIL_ADDRESS>
Closed #533.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tdlib/td/issues/533#event-2307756612

have question? what will be if i will try to match by message.date + message.chatId, can it be guaranteed that message date will not be changed for the same message but for different users? talking only about simple direct chat?

can it be guaranteed that message date will not be changed for the same message but for different users?

No, you can't assume that the date is the same.

May be someone can create useful documentation for such cases? there is no word about such behavior anywhere except

Data seen by other users are completely unrelated and useless for the current logged in users.


sanity driver for mini app management

We want admins to be able to control what micro-frontends will be available to certain users (verify, issue, see reports). This ticket is to create a driver to use the Sanity CMS as the management UI for this capability.

Not really relevant anymore.


AudioPlayer throws AudioPlayerError randomly after some time playing.

Please describe the problem you are having in as much detail as possible:
Recently, I updated my music bot from discord js v12.5.3 to v13.1.0 and since then I've been experiencing the error AudioPlayerError being thrown after some time playing.
[AudioService/joinChannel (player)]:  AudioPlayerError: aborted
    at connResetException (node:internal/errors:691:14)
    at TLSSocket.socketCloseListener (node:_http_client:407:19)
    at TLSSocket.emit (node:events:406:35)
    at node:net:672:12
    at TCP.done (node:_tls_wrap:580:7) {
  resource: AudioResource {
    playbackDuration: 30560,
    started: true,
    silenceRemaining: -1,
    edges: [ [Object] ],
    playStream: WebmDemuxer {
      _readableState: [ReadableState],
      _events: [Object: null prototype],
      _eventsCount: 5,
      _maxListeners: undefined,
      _writableState: [WritableState],
      allowHalfOpen: true,
      _remainder: null,
      _length: 540672,
      _count: 540508,
      _skipUntil: null,
      _track: [Object],
      _incompleteTrack: {},
      _ebmlFound: true,
      [Symbol(kCapture)]: false,
      [Symbol(kCallback)]: [Function: bound onwrite]
    },
    metadata: null,
    silencePaddingFrames: 5,
    audioPlayer: AudioPlayer {
      _events: [Object: null prototype],
      _eventsCount: 2,
      _maxListeners: undefined,
      subscribers: [Array],
      _state: [Object],
      behaviors: [Object],
      debug: [Function (anonymous)],
      [Symbol(kCapture)]: false
    }
  }
}

Include a reproducible code sample here, if possible:
    private async joinChannel(guildId: string, channelId: string): Promise<{ player: AudioPlayer, connection: VoiceConnection }> {
        const {voiceAdapterCreator: adapterCreator} = await this._client.guilds.fetch(guildId);

        const connection = joinVoiceChannel({
            channelId,
            guildId,
            adapterCreator,
        });

        const player = createAudioPlayer();
        connection.subscribe(player);

        connection.on("stateChange", (_, newState) => {
            if (newState.status === VoiceConnectionStatus.Disconnected) {
                if (newState.reason === VoiceConnectionDisconnectReason.WebSocketClose && newState.closeCode !== 4014) {
                    connection.rejoin();
                }
            } else if (newState.status === VoiceConnectionStatus.Destroyed) {
                this.stop().catch((e) => console.error("[AudioService/joinChannel (connection/stateChange)]: ", e.toString()));
            }
        });
        connection.on("error", (error: Error) => {
            console.error("[AudioService/joinChannel (connection)]: ", error.message);
            this.stop().catch((e) => console.error("[AudioService/joinChannel (connection/error)]: ", e.toString()));
        });

        player.on("stateChange", (_, newState) => {
            (async () => {
                if (newState.status === AudioPlayerStatus.Idle) {
                    if (this._queue.length === 0) {
                        await this.stop();
                    } else {
                        await this.prepareAndPlay();
                    }
                }
            })().catch(e => console.error("[AudioService/joinChannel (player/stateChange)]: ", e.toString()));
        });
        player.on("error", async (error: Error) => {
            console.error("[AudioService/joinChannel (player)]: ", error);
            this.stop().catch((e) => console.error("[AudioService/joinChannel (player/error)]: ", e.toString()));
        });

        return {
            player,
            connection
        };
    }

Further details:
Tested on 3 environments.
Windows Machine

@discordjs/voice version: 0.6.0
Node.js version: v16.9.1
Operating system: Windows 10 21H1

Raspberry pi 3

@discordjs/voice version: 0.6.0
Node.js version: v16.9.1
Operating system: Raspbian GNU/Linux 10 (buster)

GCP VM (Not as frequently as the others)

@discordjs/voice version: 0.6.0
Node.js version: v16.9.1
Operating system: Debian GNU/Linux 10 (buster)
Priority this issue should have – please be realistic and elaborate if possible: Moderate

Relevant client options:

gateway intents: GUILDS, DIRECT_MESSAGES, GUILD_MESSAGES, GUILD_VOICE_STATES, GUILD_MESSAGE_REACTIONS

[AudioService/joinChannel (player)]:  AudioPlayerError: aborted

This is a ytdl-core issue. Nothing discord.js can do.
Anyone close this issue with external fault


Multi-arch support

Looks like the buildah can build multi-arch images: https://github.com/containers/buildah/issues/1590
Can we use it in this action?

@lexfrei 👋🏻
I think support to build mult-arch images will be a good addition.
We will update you once we start working on this feature :)

is this just the -arch argument?
this user also points out you need to have qemu-user-static installed
https://github.com/containers/buildah/issues/1590#issuecomment-771924743

Hi @lexfrei this feature is now added in v2 version of the action.

Hi!
I'm trying to initiate a multi-arch build though it's failing.
My failed workflow can be found here
I have set.
    - name: Build Image
      id: build-image
      uses<EMAIL_ADDRESS>      with:
        image: tumbleweed-dnf-toolbox
        tags: ${{ env.SHORT_SHA }} ${{ env.SNAPSHOT }} latest
        archs: amd64,ARM64
        oci: true
        context: images/opensuse/tw/dnf
        dockerfiles:
          ./images/opensuse/tw/dnf/Dockerfile

I can build just fine on the CLI like buildah bud --arch amd64,ARM64 -t anthr76-devops-toolbox:20210305 .

hi, @anthr76 I tried some commands locally and can confirm the buildah bud command you posted works.
however skopeo shows some strange behaviour here, I wonder if it may be similar to your issue.
If i pass --overide-arch arm64 it works
[ /opensuse/tw/dnf ] 54 (master) $ skopeo inspect --override-arch arm64 docker://registry.opensuse.org/opensuse/tumbleweed-dnf
{
    "Name": "registry.opensuse.org/opensuse/tumbleweed-dnf",
    "Digest": "sha256:01b2e718a5c9ee53a34912b049aaf942b5a10fdf6b76385f7d3ff83ec3ca5fd8",
    "RepoTags": [
<etc>

If I pass --override-arch ARM64 I get the same error as your workflow
[ /opensuse/tw/dnf ] 54 (master) $ skopeo inspect --override-arch ARM64 docker://registry.opensuse.org/opensuse/tumbleweed-dnf
FATA[0000] Error parsing manifest for image: Error choosing image instance: no image found in manifest list for architecture ARM64, variant "", OS linux

Can you try using lowercase "arm64" :)

Hey there @tetchel !
Thanks for taking a look! This is interesting as I originally had that.
I now receive the error on the image from OpenSUSE's registry  (registry.opensuse.org/opensuse/tumbleweed-dnf), but not on the image I layered!

https://github.com/anthr76/tooling/runs/2047204867?check_suite_focus=true (fail)
https://github.com/anthr76/tooling/runs/2047199421?check_suite_focus=true (pass)

Which an interesting pattern, of which I'm assuming is a Buildah bug or an issue with the SUSE image. Though the SUSE image is indeed multi-arch. This can actually be re-produced on the CLI with both casings of arm.
buildah bud --arch amd64,ARM64 -t tumbweed-toolbox-dnf:20210306 .
STEP 1: FROM registry.opensuse.org/opensuse/tumbleweed-dnf
error creating build container: Error choosing an image from manifest list docker://registry.opensuse.org/opensuse/tumbleweed-dnf:latest: no image found in manifest list for architecture amd64,ARM64, variant "", OS linux
ERRO exit status 12

Sorry, I deleted my comment because I wanted to investigate further.
I wonder if the problem could be worked around by doing a buildah pull --arch with each arch you want, before doing the bud.
Another workaround worth trying is building the architectures separately (using a matrix strategy), ie one with --arch arm64 and another with --arch amd64.

I wonder if the problem could be worked around by doing a buildah pull --arch with each arch you want, before doing the bud

This worked (at least on the CLI)! Neat workaround. Wonder what exactly is causing this..

Hey folks :wave: Is there any chance that the buildah-build action might support the --platform multi-arch buildah option in future?  (I can open a feature request if that's better than asking in here)
(as I understand it / for context: --platform is a way to provide --os, --arch and --variant within a single parameter, so it conflicts with those if they are set)

@jayaddison  https://github.com/redhat-actions/buildah-build/issues/65

Thanks, @tetchel!


control speed of fade

Are there controls for how fast the toast notification fadesIn and fadeOut?

Hi,
you can rewrite css definition of transition in toaster.css file, or overwrite it in your custom css file.
Jiri.

Got it


resolved issue 1121

Resolves #1121.
The depend on https://github.com/mesosphere/mesos-utils/pull/18 being merged and published before it can be merged (replacing the SNAPSHOT dependency with the stable one, once it exists).

@eigenvariable these changes need to be rebased before they can be merged.

As there is no activity here and we really need to get this done I created a new PR here: https://github.com/mesosphere/marathon/pull/1384
Closing this.


Update travis build to use official Mono

Travis CI introduced recently the possibility to build mono projects in a semi official way: https://docs.travis-ci.com/user/languages/csharp/
The changes here make use of that functionality instead of manually downloading and installing Mono on an OSX machine. Now the build will be performed on Linux and we can even add multiple Mono versions to test.
NAnt and NUnit are still installed manually.

By the way, with the change to boo-lang/boo, we´ll need to bind the new repo in travis-ci.org

Thanks! I'll update the travis.

Travis has been updated but currently failing to download mono.


Several issues: no identity, public default handlers, updating NuGET restore packages

Hello,
I'm evaluating the WebDAV for the project and have a few code changes that I would like to discuss or pull into the master. Specifically:

I would like the server to handle some URLs without authentication (with default identity) - this leads to NullPointerException on the line https://github.com/WebDAVSharp/WebDAVSharp.Server/blob/master/WebDAVServer.cs#L245.
There is a typo in https://github.com/WebDAVSharp/WebDAVSharp.Server/blob/master/WebDAVExtensions.cs#L72 - it compares url with uri.
I would like to use prefix "http://*:PORT/". Even if type 2) is fixed, it will not construct a proper handler.
NuGET can be migrated - http://docs.nuget.org/Consume/Package-Restore/Migrating-to-Automatic-Package-Restore

If you agree with the changes, I would be happy to make a pull request. Should I just create it for master or for some another branch?
Thanks.

Hello
I certainly agree with options 2 and 4.
But I have a question about option 1, which URLs would you like to reach with a default identity?
And about option 3, do you mean that PORT should be a variable?
The branch called development is being used for development purposes. If you could make a pull request to that branch, that would be great.
https://github.com/WebDAVSharp/WebDAVSharp.Server/tree/development
Thank you for having interest in the project.
Sincerely yours,
Ewout.

I'm merging WebDAV server with existing service with own HTTP-derived protocol and some of its URLs should be publicly accessible. Currently I've implemented it by adding custom HTTP method handlers to WebDAV instance but it requires some workarounds like moving authentication and making buildin WebDAV handlers public. Something like that:
let handlers = [ [ _wdMethodHandlers ]; [ for item in WebDavMethodHandlers.BuiltIn do yield item ] ] |> List.toSeq |> List.concat
wdServer <- Some(new WebDavServer(new WebDavDiskStore(@"c:\Projects\WebDAVStorage"), _listener, handlers))

This work is ongoing so no rush - I will come up with something to discuss later.

Ok, will do.

No, it is * what cause troubles now - the GetPrefixUri looks for the prefix by comparing the URL with prefix but in case the prefix is http://*:81/ (for example) and the URL is http://localhost:81/ then this approach will not work. Currently I've fixed it by substituting * with the URL's host.

Ok. Will do.

Thank you for having interest in the project.

You are welcome :) It looks like it is the best WebDAV implementation in the NuGET so far.

2, 3, 4 - pull requests: https://github.com/WebDAVSharp/WebDAVSharp.Server/pull/8 and https://github.com/WebDAVSharp/WebDAVSharp.Server/pull/7
1. I've solved it by returning context in the HttpListener wrapper:
let _listener = {
    new IHttpListener with

        member x.GetContext abortEvent =
            let ctx = _getHttpListenerContext(abortEvent)
            match ctx with

and _getHttpListenerContext is
let rec _getHttpListenerContext abortEvent =
    let ar = _httpListener.BeginGetContext(null, null)
    let index = WaitHandle.WaitAny([| abortEvent; ar.AsyncWaitHandle |]);
    if index = 0 then
        None
    else
        let context = _httpListener.EndGetContext(ar)
        let request = context.Request

        sprintf "Request: %s %s" request.HttpMethod request.Url.AbsolutePath |> _peerLog

        let someContext = match request.HttpMethod with
                          | "xxx" -> HandleRequest context; None
                          | ...
                          | _ -> Some(context)
        match someContext with
        | Some(_) -> someContext
        | _ -> _getHttpListenerContext(abortEvent)

in this way the request is first processed by my router and then passed to the server. So no changes are necessary.

Feel free to reopen if you have questions


Doesn't apply magical sleep resistance when importing race shadar-kai

Describe the bug
When importing a character of the  shadar-kai race it doesn't import it's magical sleep resistance.
To Reproduce
Steps to reproduce the behaviour:

Create a DnD Beyond character that's a shandar-kai
Import to Foundry
Notice lack of resistance in VTT vs DnD Beyond

Expected behaviour
Magical sleep resistance to be added to resistances same as DND Beyond Character sheep
Environment:

Browser Any
Foundry Version 11.315
5e System Version 3.2.1
Module Version [e.g 3.1.21]
Does this behaviour occur with other modules disabled: Yes

Additional context
The race description lacks the explicit mention of magical sleep resistance, which is why i assume it doesn't get added.

https://www.dndbeyond.com/characters/126889707
Details of any errors in the browser console (press F12). N/A

I have a fix for this but it won't be out for a little while as its part of a broader refactor for some features.

Resolved in 6.0.0


Please add feign's repository link to the project reference

Is your feature request related to a problem? Please describe.
https://docs.spring.io/spring-cloud-openfeign/docs/current/reference/html/#spring-cloud-feign-overriding-defaults says:

The OkHttpClient and ApacheHttpClient and ApacheHC5 feign clients can be used by setting feign.okhttp.enabled or feign.httpclient.enabled or feign.httpclient.hc5.enabled to true, respectively, and having them on the classpath.

but it doesn't tell us which package should we depend to having these classes on the classpath.
Describe the solution you'd like
Add at least https://github.com/OpenFeign/feign to the reference page, and don't forget to add a note that users should use the same version with feign-core, or NoClassDefFoundException may thorws.
Additional context
I added a latest version of feign-okhttp to a project with spring cloud 2020.0.6, which uses feign-core 10.12 inside spring-cloud-starter-openfeign, then the unit test failed as some class cannot be found 🤣

Hello @DevDengChao, thanks for reporting the issue. Makes sense to add link to Feign project to the docs - will do. However, when it comes to Feign dependencies, you should not specify the version on your own at all. If you are using Spring Cloud dependency management bom (which you should be doing), the correct version of the dependency will be resolved for  you.

Actually, the reference is also link there in the first point of the documentation: https://docs.spring.io/spring-cloud-openfeign/docs/current/reference/html/#spring-cloud-feign.


NoMethodError: undefined method `client' for ShopifyAPI::GraphQL:Class

I am using gem version 9.0.0.
sometimes it works fine but sometimes I got an error that the client is an undefined method in line
ShopifyAPI::GraphQL.client
Versions Breakdown

Rails(<IP_ADDRESS>)
Ruby(2.5.1)
Shopify App(11.6.0)
Shopify Api(9.0.0)

Can you give us more code and more context? It is hard to tell what you are doing and what is happening with this.


Add workflow to enter insulin

Some Loop users would like a way to log insulin doses that aren’t from the pump (e.g. injections or Afrezza to handle highs). A workflow (probably pretty similar to “Enter carbs”) would help with this. Thanks for consider it!

No problem. I’m not able to test carefully right now, but I created a workflow that makes the most basic possible Nightscout entry containing insulin. The entry is saved in the treatments collection on mongo, but there’s no event type (like “correction bolus”, etc), duration, or other information that would be contained in a treatment that was logged through CarePortal in Nightscout. Those would be easy things to add, but let’s start here. This URL should let you see the workflow and test it out. Please do so with caution, particularly if you are on OpenAPS or any system where the information in Nightscout might be used to make future treatment decisions.
https://workflow.is/workflows/6d7074cc084948a2a5433b41b1ddd1ce


onType option not woking in Helix editor

Component:

LSP (used with other editor)

LSP version: 0.12.1, commit 0d5b9330a1d515fa47456e755f751ea4056282b8 (Typst version 0.10.0)
OS version and name: macOS 14.0

I am on the latest stable version of the extension/LSP.
I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Here is my lsp configuration for the Helix editor:
[[language]]
name = "typst"
scope = "source.typst"
injection-regex = "^typ(st)?$"
file-types = ["typ"]
roots = []
language-servers = ["typst-lsp", "prosemd"]
[language.auto-pairs]
'(' = ')'
'{' = '}'
'[' = ']'
'"' = '"'
'`' = '`'
'$' = '$'

[language-server.typst-lsp]
command = "typst-lsp"
config = { exportPdf = "onType" }
roots = []
comment-token = "//"
indent = { tab-width = 2, unit = " " }
formatter = { command = "typstfmt" }
text-width = 100
rulers = [100]
soft-wrap.wrap-at-text-width = true

Even though I set the export-pdf option to onType, it does not compile onType and instead only compiles onSave.
Thanks in advance for any help!

Ah never mind, looks like the issue resolved itself...


Add modern cmake

This adds support for building and installing this package with cmake, so that it can be used from other packages with a simple cmake interface and without having to copy headers:

Add cmake interface so that the installed library can be used from other projects via find_package(cppflow) and target_link_libraries(new_target PUBLIC cppflow)
Simplify examples cmake code by using the new cmake interface
Build all examples unless -DBUILD_EXAMPLES=OFF is passed
Enable out-of-source build by fixing hard-coded paths

An example out-of-source build would look like this:
git clone https://github.com/serizba/cppflow
cd cppflow
mkdir build
cd build
cmake -DBUILD_EXAMPLES=ON ..
make -j8

# Test run one of the examples
./examples/multi_input_output/multi_input_output

# This installs c++ code and cmake interface to system directories and enables other packages to find cppflow via 'find_package(cppflow)'
make install

Hi @fferflo
Thanks for your time. This looks interesting. I will take a look as soon as I have time.
Thanks!

I've look at this pull request and I would love to use it on my code. @serizba, could you look at it again, please?

I need this in my code as well, this is the way the libraries should be used.

Hi @fferflo @Gonzalo-Mier @mkazharov !
Sorry for not doing this before. I have little experience with CMake, and I didn't give this much attention. But I see that people are looking forward to this addition.
I have two doubts (arising from my lack of experience with CMake):

How should the Tensorflow C API be installed to work with this setup? Globally into ´/usr/local´?
I like to see the examples as a standalone example of how to do basic stuff with the library. I think for some users is useful to have a basic example from where they can start (they can copy the ´load_model´ example and start working from there). With these changes the examples are like submodules of the library, and thus they cannot be used as a starting template.

Could the examples CMake be changed into standalone CMakes? Or what do you guys think about this?
I think some people use this library as a pattern for interacting with TensorFlow C API. So they clone it, modify it to their needs and then use they modified version. For this reason I like to have a flexible installation that does not require to globally install CppFlow once. That's why I pointed this two doubts.
Anyway, I really like your changes, and I think they are a good addition to the library.

@serizba In my opinion, the proposed cmake in this pr is better, because it makes unit testing much easier. In addition, other cmake project can just include this project.
To answer your questions

From the cmake files, it looks for tensorflow_INCLUDE_DIRS and tensorflow_LIBRARIES for TF C Lib.
Apparently, it is not easy to keep both versions. One of the options is to rename the old CMakeLists.txt to something else, e.g. CMakeLists_standalone.txt. In addition, the cmake file adds the option to install cppflow to some place, but people do not have to do so. They can still keep the modified cppflow in their own source projects and manage it with cmake locally.

Thanks for your explanation @ljn917!
For the first point. If I have the TF C API in a specific folder, then how can I specify the value of tensorflow_INCLUDE_DIRS? Something like -Dtensorflow_INCLUDE_DIRS=/home/...? Or should I change the Findtensorflow.cmake adding a HINTS?
For the second point I think the best way is to change the CMake of the examples to the one in this PR (to keep the PR code). For the standalone CMake I can include it in the docs, showing how to run the examples.
How would a proper CMakeLists.txt for the examples look then?
Sorry for my lack of experience with CMake :)

Hi @serizba,
Thanks for considering this PR. I'm only answering to the second question, because I do not install the library due to its small size (I download and compile it together with my project when need it). I learnt how to use cmake efficiently recently from this tutorial: https://cliutils.gitlab.io/modern-cmake/
I created a cmake using the one in this PR as template. I removed examples and documentation information as I don't want to continuously compile them, and added support for FetchContent.
Doing these changes, I can add my version of CPPFlow to my personal projects as:
cmake_minimum_required(VERSION 3.14)
project(MyExample VERSION 1.0 LANGUAGES CXX)

FetchContent_Declare(cppflow
  URL https://github.com/Fields2Cover-group/cppflow/archive/refs/heads/master.zip
)
FetchContent_MakeAvailable(cppflow)

add_executable(MyExample simple_example.cpp)
target_link_libraries(MyExample PUBLIC cppflow)

I know this is not the original way of using the PR, but I add it as another easy way to use the library without install it thanks to cmake. Feel free to take what you need from my fork and thank you for your amazing job.

@serizba I think -Dtensorflow_INCLUDE_DIRS=... should work, though I have not tested it. In addition, it may be better to accept the top dir of tensorflow c api as  TENSORFLOW_C_API_DIR and then add the include and lib later in the cmake.

For the first point. If I have the TF C API in a specific folder, then how can I specify the value of tensorflow_INCLUDE_DIRS?

The canonical cmake way is to add the root directory of tensorflow api to CMAKE_PREFIX_PATH (as environment variable or via -DCMAKE_PREFIX_PATH=...) if it's not installed in system directories. This enables find_package to find the library (by calling find_library) and include directory (by calling find_path) and automatically add them to the target cppflow.

Thanks for your help!
Still I don't know how to create a simple CMakeLists.txt for a simple example. If I install first the cppflow library, and now I want to work with in another project, and another directory. I can call find_package(cppflow REQUIRED), but how can I obtain the include dirs of cppflow?
I've tried to create a CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)

project(example)

add_executable(example main.cpp)

find_package(cppflow REQUIRED)

target_include_directories(
  example
  ??????????
)

target_link_libraries(
  example
  ??????????
)

I've tried with ${cppflow_INCLUDE_DIRS} and ${cppflow_LIBRARIES} but they don`t exist.

@serizba Can you try cppflow::cppflow in the place of ???????????

Thanks @ljn917, that works!

@serizba and the others, thanks a lot for your effort, sorry I couldn't contribute!

This adds support for building and installing this package with cmake, so that it can be used from other packages with a simple cmake interface and without having to copy headers:

Add cmake interface so that the installed library can be used from other projects via find_package(cppflow) and target_link_libraries(new_target PUBLIC cppflow)
Simplify examples cmake code by using the new cmake interface
Build all examples unless -DBUILD_EXAMPLES=OFF is passed
Enable out-of-source build by fixing hard-coded paths

An example out-of-source build would look like this:
git clone https://github.com/serizba/cppflow
cd cppflow
mkdir build
cd build
cmake -DBUILD_EXAMPLES=ON ..
make -j8

# Test run one of the examples
./examples/multi_input_output/multi_input_output

# This installs c++ code and cmake interface to system directories and enables other packages to find cppflow via 'find_package(cppflow)'
make install

It would help out a C++ newbie like myself if the docs were updated with these instructions. Going to the current install page: https://serizba.github.io/cppflow/installation.html it looks like it only has instructions to install Tensorflow C libraries

Hi @garricklw
You are completely right! I had in mind changing the docs, I will try to do it sooner, its definitely an issue for newbies.
Thanks!

Hi @garricklw
I updated the docs, thanks for pointing this!

Thanks @serizba, I think that'll help out a lot for the next newbie who comes along. After running those steps everything is working great for me.


chore: update node version for semantic-release

:tada: This PR is included in version 0.9.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


enable REFERENCES on ALTER TABLE FOREIGN KEY deparsing

When using ALTER TABLE, the REFERENCES keyword was not working.  This fixes queries like the following:
ALTER TABLE "distributors" ADD CONSTRAINT distfk FOREIGN KEY ("address") REFERENCES "addresses" ("address");
ALTER TABLE "distributors" ADD CONSTRAINT distfk FOREIGN KEY ("address") REFERENCES "addresses" ("address") NOT NULL;

@Winslett Thanks for the continued work here!
One thing that we could look into, which is what @zhm did for the node libraries, is to use the PostgreSQL regression test suite as a source of SQL we want to be able to deparse.
He essentially used it to parse the SQL query, deparse, and parse again - comparing the parse trees and seeing if they match.
If thats useful to you (not sure if you have a good set of test data already?) I'd be happy to look into it :)

I've been thinking the deparsing tests needs to be cleaned up / modularized, but had not considered the fixture method.  The node library looks like a good organization scheme.
I don't really have "test" data.  We use this gem in our UI for parsing free-form SQL submitted by customers to their hosted database.  The PRs so far have been from customers finding failing deparsing cases.
On our next PR, I'll see what I can do to shape it up.

@Winslett Sounds good & thats a great use case - happy to see the library being used there!


Building data-rich web apps with Lovefield - Link to the demo source code is missing in documentation

The page missing the documentation link:
https://io2015codelabs.appspot.com/codelabs/lovefield
Look for this at the bottom of Step 1:
"The StockAnalyzer skeleton code (instructions on downloading available at “Step 0”)."
There is no "Step 0" and there is no hint as to where to find the "StockAnalylzer skeleton code". When I search the GH repo (via the link to reporting bugs) I do see the zip file for this missing data file.
https://github.com/googlesamples/io2015-codelabs/blob/master/lovefield/stock_analyzer.zip

Nevermind. This is NOT AN ISSUE.
I found it in:
"3. Step 0: Download and run the skeleton code"

FWIW, you can also find the codelab at https://github.com/google/lovefield/blob/master/codelabs/stock_analyzer/docs/codelab.md, along with all the code.

Closing since this is a non-issue, as stated in comment 2.


Introduce support for per-call memory allocator for caching

What this PR does:
This change adds the ability to pass a memory allocator to caching methods via their context argument. This allows the underlying client to use memory allocators better suited to their workloads than GC. This is only used by the Memcached client at the moment.
Which issue(s) this PR fixes:
See grafana/mimir#3772
See grafana/gomemcache#8
Signed-off-by: Nick Pillitteri<EMAIL_ADDRESS>Checklist

[X] Tests updated
[X] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

This approach currently uses a context.Context object to pass an Allocator instance to the various caching layers. I'm not sure if this is a hacky way of "passing optional parameters to functions". In my mind an allocator isn't really something you'd normally pass as an argument. Do people have thoughts or opinions on this?

This approach currently uses a context.Context object to pass an Allocator instance to the various caching layers. I'm not sure if this is a hacky way of "passing optional parameters to functions". In my mind an allocator isn't really something you'd normally pass as an argument. Do people have thoughts or opinions on this?

My 2c: I would prefer an Options-style parameter, like what you introduced in gomemcache, although I agree that it feels a bit weird.
Rationale:
As a consumer of this library, an Options-style parameter makes the functionality more discoverable, whereas using a context.Context, I'd need to do a bit more digging to find it. (Documentation might help mitigate this though.)
Using parameters would also help avoid annoying bugs - for example, imagine a scenario where we had a couple of different libraries that all expected the allocator to be passed in the context.Context, each with their own WithAllocator(ctx, allocator) method. It'd be really easy to accidentally use the wrong WithAllocator method, and it wouldn't be immediately obvious that you'd done this: instead, we'd just silently use the default allocator. With parameters or an Options-style parameter, either you've set the allocator (and type safety prevents any confusion), or you haven't.


typo raw -> row

raw -> row
https://github.com/Jij-Inc/ommx/blob/260f6a83983bb8aade38a986e815682498431fd8/python/ommx/ommx/v1/__init__.py#L642

Thank you for reporting the bug.
This is a very minor typo, so we'll fix it right away.

Fixed in #119


installing error

i launch
'''shell
sudo python setup.py install
'''
and i have this error :
'''Shell
building 'max7219.spi' extension
creating build/temp.linux-armv6l-2.7
creating build/temp.linux-armv6l-2.7/src
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c src/spi.c -o build/temp.linux-armv6l-2.7/src/spi.o
src/spi.c:20:20: fatal error: Python.h: Aucun fichier ou dossier de ce type
compilation terminated.
error: command 'gcc' failed with exit status 1
'''

it's ok, just i have python by default but not python-dev

Glad you found the problem -- I'll add a section to the readme file to indicate that python-dev is a pre-requisite


Standardize PVC component names

Overview
We don't have a standard for our component names, having three different variants:

Primer::ButtonComponent - with suffix
Primer::AutoComplete - no suffix
Primer::Alpha::ButtonMarketing - status as a module

This causes confusion and a not ideal developer experience, so we should have a single naming standard.
Proposal
Rename all components to have their status as a module and remove the Component suffix.
Examples:

Primer::ButtonComponent -> Primer::Beta::Button
Primer::AutoComplete -> Primer::Beta::AutoComplete

Removing the suffix will make working with components less verbose. Using the status as a module will help with status promotion because we can keep the previous version for some time, giving users time to migrate.
How to migrate a component
The majority of the work is done through the component_status_migrator thor command. This command will move files, update references, create a deprecated component in place of the original, fix navigation in storybook and the doc site, and more.
Run a migration
As an example, the above referenced Primer::ButtonComponent can be migrated with the following command line:
bundle exec thor component_status_migrator ButtonComponent --status beta

Note that this command specifically calls out the target status for the component in --status beta. If this option is left off, it will default to alpha and move the component into the corresponding alpha folder and Alpha:: namespace.
Be sure to set the correct status when migrating a component. Valid status entries include:

alpha
beta
stable
deprecated (not fully supported yet)

Testing a migration
Prior to creating a pull request and marking it as ready for review, be sure to run all tests, check storybook, and check the docs site to ensure all updates have been made:

run script/test
run script/dev

go to http://localhost:5000 to check storybook
go to localhost:5400 to check the doc site

Common errors
You may run into errors with storybook or the docs site, due to previously built site information. For example, storybook may still have the original Primer::ButtonComponent entry while also having the updated Primer::Beta::Button entry. If this happens, you will need to clean out the build cache and rebuild. One way to do that is to run the following:

git clean -dfx
script/setup

The first call to clean will remove all untracked files and folders that are not part of .gitignore. The second call will remove all untracked files and folders that are part of .gitignore. This will remove everything, including nod_modules and bundle vendor folders. After that, you'll need to run script/setup to reinstall and rebuild before running script/dev again.
Example pull requests
See the component migration work that is already completed, below, for example pull requests.
Work TODO
component status migrator code changes:

[x] update component_status_migrator.thor script to handle --status stable https://github.com/primer/view_components/pull/1262
[x] automate additional manual tasks for replacing references and updating files https://github.com/primer/view_components/pull/1269
[x] correct the docs site nav.yml when migrating a component https://github.com/primer/view_components/pull/1276
[ ] update component_status_migrator.thor to support migrating from alpha or beta folder, to correct status destination https://github.com/primer/view_components/issues/1263

todo / in progress component migrations:

[ ] Primer::LayoutComponent (needs deprecation config w/ migration guide)
[ ] Primer::Truncate (needs deprecation config w/ migration guide)
[ ] Primer::Navigation::TabComponent https://github.com/primer/view_components/pull/1730
[x] Primer::TimelineItemComponent::BadgeComponent https://github.com/primer/view_components/pull/1729

completed component migrations:

[x] Primer::AutoComplete https://github.com/primer/view_components/pull/678
[x] Primer::AutoComplete::Input https://github.com/primer/view_components/pull/678
[x] Primer::AutoComplete::Item https://github.com/primer/view_components/pull/678
[x] Primer::AvatarComponent https://github.com/primer/view_components/pull/687
[x] Primer::AvatarStackComponent https://github.com/primer/view_components/pull/707
[x] Primer::BaseButton https://github.com/primer/view_components/pull/1243
[x] Primer::BlankslateComponent (deprecated version is still live, due to API changes)
[x] Primer::BorderBoxComponent https://github.com/primer/view_components/pull/1255
[x] Primer::BoxComponent https://github.com/primer/view_components/pull/1266
[x] Primer::BreadcrumbComponent
[x] Primer::BreadcrumbComponent::ItemComponent
[x] Primer::ButtonComponent https://github.com/primer/view_components/pull/1271
[x] Primer::ButtonGroup https://github.com/primer/view_components/pull/1275
[x] Primer::ClipboardCopy https://github.com/primer/view_components/pull/1674
[x] Primer::CloseButton https://github.com/primer/view_components/pull/1277
[x] Primer::CounterComponent https://github.com/primer/view_components/pull/1279
[x] Primer::DetailsComponent https://github.com/primer/view_components/pull/1280
[x] Primer::Dropdown
[x] Primer::Dropdown::Menu
[x] Primer::Dropdown::Menu::Item
[x] Primer::DropdownMenuComponent
[x] Primer::FlashComponent
[x] Primer::HeadingComponent https://github.com/primer/view_components/pull/1297
[x] Primer::HiddenTextExpander https://github.com/primer/view_components/pull/1303
[x] Primer::IconButton https://github.com/primer/view_components/pull/1397
[x] Primer::Image https://github.com/primer/view_components/pull/1527
[x] Primer::ImageCrop https://github.com/primer/view_components/pull/1528
[x] Primer::LabelComponent https://github.com/primer/view_components/pull/1530
[x] Primer::LinkComponent https://github.com/primer/view_components/pull/1532
[x] Primer::LocalTime https://github.com/primer/view_components/pull/1687
[x] Primer::Markdown https://github.com/primer/view_components/pull/1681
[x] Primer::MenuComponent https://github.com/primer/view_components/pull/1682
[x] Primer::OcticonComponent https://github.com/primer/view_components/pull/1690
[x] Primer::OcticonSymbolsComponent https://github.com/primer/view_components/pull/1696
[x] Primer::PopoverComponent
[x] Primer::ProgressBarComponent
[x] Primer::SpinnerComponent https://github.com/primer/view_components/pull/1698
[x] Primer::StateComponent https://github.com/primer/view_components/pull/1716
[x] Primer::SubheadComponent https://github.com/primer/view_components/pull/1720
[x] Primer::TabContainerComponent https://github.com/primer/view_components/pull/1725
[x] Primer::TabNavComponent
[x] Primer::TimeAgoComponent https://github.com/primer/view_components/pull/1692
[x] Primer::TimelineItemComponent https://github.com/primer/view_components/pull/1727
[x] Primer::Tooltip
[x] Primer::UnderlineNavComponent
[x] Primer::HellipButton https://github.com/primer/view_components/pull/1726

I made an embarrassingly nasty script in https://github.com/primer/view_components/pull/701 that we hack on that I think should save us a bunch of time in this work.

This issue has been getting stale for a while, and having a mix of naming conventions in the codebase is confusing for us library engineers and the developers using it.
I think it would be good to make a concerted effort to migrate the component names (possibly in one dedicated release?) and be done with it. Manuel and I have been working on changes to the migration script so that we can alias the old name to the new name, thereby running the migration in a non-breaking way. See https://github.com/primer/view_components/pull/975
I hope we have the script complete and tested this week so we can start the migration next week if we're all happy.

Since https://github.com/primer/view_components/pull/1441 was merged, Primer::FlexComponent and Primer::FlexItemComponent should be removed.

The components Primer::LocalTime and Primer::TimeAgoComponent may be able to be removed from this issue once #1650 is merged.

Since https://github.com/primer/view_components/pull/1650 was merged, Primer::LocalTime and Primer::TimeAgoComponent can be removed from this issue.

Why is Primer::LinkComponent migrated to Primer::Beta::LinkComponent? I thought that the Component suffix should be removed from all of the components.

@ollie-iterators

Why is Primer::LinkComponent migrated to Primer::Beta::LinkComponent? I thought that the Component suffix should be removed from all of the components.

oops! that was a mistake in the title of the PR. the component is Primer::Beta::Link. i've updated the PR title. don't know how long it will take for the link here to reflect that

The Pull Request: https://github.com/primer/view_components/pull/1729 was merged, so Primer::TimelineItemComponent::BadgeComponent can be marked as completed.

Since https://github.com/primer/view_components/pull/1730 was merged, Primer::Navigation::TabComponent's check box should be checked.

Since https://github.com/primer/view_components/pull/1877 was merged, Primer::Truncate can be checked off.

Thanks @ollie-iterators. @hrs can you confirm https://github.com/primer/view_components/issues/676#issuecomment-1466713881 has been completed and update the summary task list if so?

I don't know if Primer::LayoutComponent has been migrated yet

Yup, that's all right! Primer::Truncate has been migrated and checked off. Primer::LayoutComponent hasn't yet been deprecated but will be shortly!

Nope, but I'm working on that one right this minute. Ought to be done before too much longer. 😄

Since https://github.com/primer/view_components/issues/1263 was closed, this Issue can be closed as completed.


[Bug] Requests for images return 401

Hi! Everthing is fine on my main browser, Firefox on Linux, where the cookie was saved a long time ago:

But when I login now from any browser (Chromium or even the same Firefox in the private mode), images won't load with an 401 error {"detail":"Invalid authentication credentials"}:

Is it possible that some of the recent updates have changed the behavior of cookie setting, leading to this?

root@tzyzhctiwx:~/smooth# docker inspect dullage/flatnotes
[
    {
        "Id": "sha256:8ab9b5e298b504b8042486eb34bca59463d7621f270f0d187280c88ef02ec88e",
        "RepoTags": [
            "dullage/flatnotes:latest"
        ],
        "RepoDigests": [
            "dullage/flatnotes@sha256:6854c8b414a4d2c1bfa3bc24b9b5b5d9016272ba2b102d59cf9f5eb521be2b36"
        ],
...

I also think it would be nice to log flatnotes version in the entrypoint.sh, if that's possible and easy to do

Also, I don't know if this relevant, but I've deployed flatnotes at flatnotes.example.ru and a few days ago I've changed the address (A-record) of example.ru, which shouldn't affect flatnotes at all. The A-record for flatnotes.example.ru is the same as it always was.

I've tried to replicate an issue, but I don't see any problem in my setup. There's certainly not been any recent changes to the cookie implementation.
Are you able to test using a direct connection to the container (i.e. using IP and avoiding any proxies)?

Well, I can't reproduce it anymore either 😄. I absolutely haven't touched my server since then, and it just started working on its own. I'll let you know if I encounter this again and maybe fix it.


Extend ability to get params from filename

Originally posted on the forum.

I believe the filename is the first, most natural and universal place to store basic metadata relative to a file's content, making it easy to sort, filter and select files, so we can find the file of interest and gain access to the information it contains.
While Hugo relies on the files stored in the /content directory as its database, I find it could leverage the filenames to be used to set params just like basic metadata and make them really usable (like in a range in the context of a list of content).
Thanks to #4494 we already can can get both date and slug from filename.
My proposal is to extend this ability to other params like (by priority to me):

weight because for long lists of content ordered by weight, it's way easier to have things shown in order in the filesystem and possibly be able to reorder content from the filename (so it removes the risk of inconsistency in the dual book if weight in filename is set in front-matter and replicated in the filename for ease of use).

date without the format limitation: YYYY-MM-DD (for instance I would prefer YYMMDD reconciled with current century) and with datetime support (see #5974 and #7298).

and possibly whatever custom param either set alone (value in filename and key in config toggler) or as key:value pairs.

For this ability to reach its full potential the behavior should be set in the config toggler including:

filename pattern and format definition (if not hardcoded like current date)
whether extracted values override the front-matter or serve as fallback

As for 1. I find @jmooring's approach really convenient:
[frontmatter.books]
# Example: 2010-09-14_my-title_100.md
filenamePattern = `^(\d{4}-\d{2}-\d{2})_(.+)_(\d+)`
date = $1
title = $2
weight = $3

[frontmatter.movies]
# Example: 2010-09-14_99_my-title.md
filenamePattern = `^(\d{4}-\d{2}-\d{2})_(.+)_(\d+)`
date = $1
title = $3
weight = $2

As for 2. it would follow the same logic as #4494, extending the :filename "special date handler":
[frontmatter]
date = [":default",":filename"]
weight = [":filename",":default"]
title = [":default",":filename"]

This would also pave the way to have content without front-matter (see #6098 )
Of course, alternatively third parties do provide actual working solutions to override .Page.Params

Bash script like this one
R users can also leverage ymlthis wrapped in blogdown's function yml_blogdown_opts

Hope this proposal will catch your attention.
Thanks for developing Hugo!

I came across this when convert my Jekyll-style site to Hugo, I would like my posts organzied like :year-:month:-:day-:slug.md, and have url as {root}/:year/:month/:day/:slug/, maybe we can just extend permalinks to add a new keyword: :jekyll, and config looks like this
[permalinks]
  posts = "/:jekyll/"

related discussion: https://discourse.gohugo.io/t/extracting-date-and-slug-from-filename/8394/8


Make sure IO is used as an argument

We need to make sure that we provide IO interfaces as argument in all relevant places.

So far, we are meeting these criteria. This is mostly about node/browser fetch and a filesystem wrapper for generators.


Fix ViewportTexture error when viewport is used from a child scene

Fix invalid errors when a separate child scene file contains a viewport and
that viewport is used for a texture in the current scene.
Fixes #27790.
Forward port of @jitspoe's #52365 to master.

Can this be cherry-picked for 3.5? I'm running into the issue this solves in 3.5 beta 5. I'm currently using the workaround others pointed out in https://github.com/godotengine/godot/issues/27790, but it'd be nice to not have to do that.
I checked this section of the code in the 3.x branch and it isn't any different, so it should be possible to cherry-pick this.

@fire-forge This PR is the forward port of a change which was merged first in 3.x: #52365
So this can't be cherry-picked because the code is already like this in 3.x.
So if it's not working, it's that the change is not enough in 3.x.


Getting error "Cannot read property 'afterContentPaint' of null" when running tests

Occasionally on our build server, I get a failing test with the following error: Cannot read property 'afterContentPaint' of null
There are only 2 hits on Google for afterContentPaint, and one of them is this issue: https://github.com/sreedhar7/ember-app-scheduler/issues/9
This addon seems to be the only thing using that library. Have you ran into this error while using ember-router-scroll?

@cclo7 Any ideas?

I am using headless Chrome to run my tests with this testem.js config:
module.exports = {
  test_page: 'tests/index.html?hidepassed',
  disable_watching: true,
  launch_in_ci: [
    'Chrome'
  ],
  launch_in_dev: [
  ],
  browser_args: {
    Chrome: [
      '--disable-gpu',
      '--headless',
      '--remote-debugging-port=9222',
      '--window-size=1440,900'
    ]
  }
};

@nrcjbarry what type of tests are you running when encountering this error? Acceptance, integration, or unit test?

@cclo7 I have only seen it happen in acceptance tests.

I too am getting this during (some) acceptance tests

I also get this on my local machine too both when running ember test and ember test --server. I'm using Ember 2.15 and Ember CLI 2.15.1.
Here is a screen shot of the stack trace on one of them:

I encountered the same issue after an upgrade to Ember.js 2.15. I dug a bit deeper into it and I may have found out the cause. I don't think the error is in ember-router-scroll but rather in ember-app-scheduler.
I provide more explanation here: https://github.com/sreedhar7/ember-app-scheduler/issues/11.

Nevermind, I got it wrong... I figured out later that this addon uses an old version of ember-app-scheduler. PR #73 updates it to the latest version and that fixed the problem for me.

I'm still getting this error in my application's acceptance tests. Wondering if 0.2.0 fixed it for everyone else?

@ryanto do you mean 0.4.0? That is the latest release.

@ryanto it was fixed for me for months up until I upgraded to Ember 3.0 last week. I started seeing this error again only on one test (the same test) every time. I fixed it by deleting my package-lock.json file and doing another npm install. I haven't seen it in the last 2 days.

I'm running master, but this could be something I'm doing in my app. Just wanted to ask.

I haven't seen this error in a month or so (which before saw quite often in our CI build).  Note we are on<EMAIL_ADDRESS>and 0.5.0 for ember-router-scroll @ryanto

I'm still seeing this error as well, fairly sporadically in acceptance tests. Using ember-router-scroll 0.5.0 and ember-app-scheduler 0.2.1. Still looking into why, but I'm curious if anyone else is still getting it, or has a suggestion for a fix.

@bantic I think it is 👇.  It's close to being done...made a PR to get the tests passing and have been awaiting feedback.  Maybe I should push to his master instead 🤔
https://github.com/sreedhar7/ember-app-scheduler/pull/15

Still seeing this. From following development on ember-app-scheduler it looks like this PR could maybe be a fix.
https://github.com/dollarshaveclub/ember-router-scroll/pull/129

@samselikoff @ryanto What version are you guys on?  Still master?  I perhaps would have thought the PR to make app-scheduler optional would have fixed it.  I would imagine your code is never calling scheduleWork, right?
https://github.com/dollarshaveclub/ember-router-scroll/blob/master/addon/index.js#L32

Ah thanks for pointing that out! I didn't realize this was an option... Let me give it a try.

@snewcomer/@ryanto heads up the issue actually seems to lie in the flushQueue from Ember App Scheduler which runs even though router-scroll isn't directly using it. Since the service is still injected and initialized these lifecycles are still happening.
I have made a PR https://github.com/ember-app-scheduler/ember-app-scheduler/pull/45 to address this and check for service lifecycles.

I'm not sure how ember-app-scheduler will handle porting back to version 2.* as listed as a dependency for ember-router-scroll.

@ryanto @bantic Whenever you have a chance, mind giving this branch a spin?  I tried it and seems to work great.  Just probably need another approval and we can merge and release a new version!
https://github.com/dollarshaveclub/ember-router-scroll/pull/139