package.json exports resolution uses fallback conditions, unlike Node

Bug Report

🔎 Search Terms

I’ve never been more confident, without searching, that I’m the first person to notice this
💻 Code

{
  "exports": {
    ".": {
      "import": "./dist/main.mjs",
      "types": "./dist/foo.d.ts"
    }
  }
}

🙁 Actual behavior
Importing this package from an ESM file, in --moduleResolution nodenext, searches for types at these locations:

./dist/main.mts
./dist/main.d.mts
./dist/foo.d.ts

🙂 Expected behavior
It should not search the types condition, because import already matched, and contained a valid target ./dist/main.mjs. Resolution here should fail for consistency with Node, which would throw a resolution error if it matched a condition but then failed to find the file specified in it.
Fixing this bug may cause more harm than good. I noticed it because I claimed that a popular library would be broken under certain conditions due to misconfigured exports, but was proven wrong in reality. I figured this may be worth documenting, but likely not worth fixing. But if someone can make a good case for why it matters, I would reconsider.

Thanks for reporting this! I think I ran into this while testing the types for a library I had created, but honestly thought it was more on something I was doing wrong than something TS would be doing wrong.
Here's an additional library I've found that has types at the end instead of at the start:
headless-ui/react and headless-ui/vue
There's probably more out there as well.

As far as whether to fix it or not:
The pro of fixing it now is that it prevents the ecosystem from continuing this behavior, and thus entrenching the behavior.
Maybe at the least there could be a warning saying "this works now, but it's incorrect and may not work in the future" or something? 🤷

Maybe at the least there could be a warning saying "this works now, but it's incorrect and may not work in the future" or something?

We don’t have a way to do warnings on the CLI, but #46861 is related.

package.json
{
  "exports": {
    ".": {
      "require": "./dist/main.js",
      "types": "./dist/foo.d.ts"
    }
  }
}

pkg layout
dist/main.js
dist/main.d.ts
dist/foo.d.ts
package.json

Which .d.ts should be loaded? Should it be dist/main.d.ts or dist/foo.d.ts? Is a sibling .d.ts lookup still a thing when dealing with exports?

Yes, sibling .d.ts lookup is always a thing, and it’s always the way I recommend people to structure packages when possible. In your example, main.d.ts would be looked up if the import was CJS-format; foo.d.ts would be looked up if the import was ESM-format.

Yes, sibling .d.ts lookup is always a thing, and it’s always the way I recommend people to structure packages when possible.

Interesting. What's the argument for that? I usually assume that an explicit "types" might be better as it's more discoverable without the additional FS check/crawl (for instance npm is labeling packages with the TS label, I didn't check how they do it exactly but I wouldn't be surprised if they would only check the package.json content).
As to the original issue, IMHO this should be fixed on a correctness basis - to match the node's algorithm. Other tools are implementing their algorithm so having this bug~ here might cause people hard-to-debug issues when types will be found by TS itself but won't be found by other tools.

I don’t mind if people want to explicitly list their types, but I dislike separating all the types into a different folder because it’s just so easy to mess up in subtle ways. Putting your .d.ts files next to your .js files is foolproof. Unfortunately it seems library authors by and large dislike this for some reason, and it causes all kinds of problems. So I recommend putting .d.ts files with their partners, for the sake of simplicity and explainability, and then if you want to add (strictly unnecessary) types keys to your package.json too, go for it.

Yeah, that's the main use case that comes to my mind. It's somewhat easy~ to create a sibling file for your package.json#main but once you start adding more "conditions" etc then we usually need a way to redirect them to that single set of .d.ts files (where other conditions in the past were just not observed by TS, so it wasn't as much of an issue).
But when parallelizing bundling and type generation, I would usually be wary of writing to the same directory at once. Writing to separate ones and using package.json#types seems to be a safer/more straightforward way.
But anyway... this all was quite offtopic. Thank you for sharing your thoughts though!

Here is another repro, was just trying to debug this for pothos
https://github.com/hayes/ts-esm-cjs-nodenext
So far the only workaround I have found is creating separate definition files for each build directory.  Currently we publish a lib directory with cjs, an esm directory with esm, and a dts directory with definitions.  To make this work, I would have to remove "types" from pacakge.json, and publish definitions in both the lib and esm directories, as well as continuing to publish in dts for backwards compatability.  Would be awesome if there was a better option that didn't require publishing 3 identical definition files for every source file

Here is another repro, was just trying to debug this for pothos
https://github.com/hayes/ts-esm-cjs-nodenext
So far the only workaround I have found is creating separate definition files for each build directory. Currently we publish a lib directory with cjs, an esm directory with esm, and a dts directory with definitions. To make this work, I would have to remove "types" from pacakge.json, and publish definitions in both the lib and esm directories, as well as continuing to publish in dts for backwards compatability. Would be awesome if there was a better option that didn't require publishing 3 identical definition files for every source file

If it helps, I hacked it so that my build step makes a copy of my index.d.ts, renames the copy to index.d.cts, and then my package exports for cjs points to that file. Everything works, and the only extra copy I have is a index.d.cts. 😬
I'm sure there's probably going to be issues with it, but it seems better than the alternatives at the moment.

@hayes I was just working around this exact issue earlier today. You can check out what we have settled on at the end in this PR: https://github.com/alexreardon/tiny-invariant/pull/150/files
With the types condition being used first it's implied that this package is treated as a CJS package (it has no package.json#type set). And importing default export from a CJS package doesn't work in node - it returns the namespace object instead of the default export.

That’s correct; https://github.com/hayes/ts-esm-cjs-nodenext is unrelated to this issue.

This bug has actually cost me some debugging time yesterday when working on some tooling. I'm not sure if I would classify it with "Fixing this bug may cause more harm than good.". There is a clearly defined expected behavior for this and diverging from it might cause somebody to ship code with incorrect assumptions based on the observed broken behavior.
We tend to groan when we consider subtle differences between bundlers, wishing that they would behave in the same way. This issue here is effectively the same as a "subtle difference between tools" and one that could be avoided since, as far as I can tell, it wasn't really introduced on purpose.

Fixing this would break 76 of the 2212 most popular packages on npm that ship their own types.

That's 3% (not nothing but also not a substantial amount, i think) of packages that were misconfigured (as in, it truly works for them by accident - which I feel is the fair assessment here since you created this issue as a bug).
Imagine that I'm implementing a package validator - like yours arethetypeswrong or publint. Should this be an issue raised by it? If yes... why, it's working fine according to TS implementation. If no... oh, I need to add code specific to TS to handle this.
A potential for a similar situation could be found in a "type bundler" tool. It should know how to correctly load types but it might have a hard time achieving 100% correctness if TS diverges from node here.
I see package.json#exports as an interoperability tool~. While it's extensible by nature (conditions ftw), it still has some core concept backed into it. This might sounds like a small issue but IMHO this only expands the (in)compatibility table that gives us migranes already. I'd much prefer to keep it smaller instead of adding columns to it 😬
At the end of the day, I think that's up to you to decide what's right here. I personally think though that it's important to establish what would be the desired behavior as if you'd be implementing this today. I just can't get behind "it's a bug but we tolerate it" myself - if it's a bug then it can/should be fixed in my mind.

The typical case here is that packages have a fundamental flaw of containing only CJS types for a dual ESM/CJS package, because those packages are depending on a build tool that produced, in the best case scenario, a pair of type declarations and JS files in one output format which were validated to be correct by TypeScript, and one set of completely unsafe JS files without types in the other output format. Then on top of that, they make a package.json mistake which, through this bug, causes TypeScript to find the one set of types that exists, when technically it should have found nothing. The experience for the end user consuming these types is that they can probably get by, instead of being totally blocked. And while the package.json ordering error is easy to correct, fixing it still leaves the package objectively misconfigured. On the other hand, if the fundamental problem of missing types is solved, then the occurrences of this bug completely vanish, because the earlier matching lookup condition doesn’t fail to resolve. But as you know, that problem is much harder to solve. It feels really bad to break 76 super popular packages for millions of users and then tell them, when they inevitably file bugs against TypeScript, that the packages are misconfigured and they have to completely ditch their whole build system, and maybe they should rethink shipping a dual ESM/CJS package entirely, just to get types—when they had probably-working types in the last version of TypeScript. People would think we’ve lost our minds.

(as in, it truly works for them by accident

It’s certainly not an accident for the package authors; through TypeScript’s accident, the package authors are getting the closest thing to their intended behavior that’s possible with missing types.

Imagine that I'm implementing a package validator - like yours arethetypeswrong or publint.
Should this be an issue raised by it?

Look, I also hate this. I want things to be correct. You will rarely see me argue that wrong module resolution is good. But shipping a break for this is not the hill I want to die on. I think we could consider it for 6.0. Alternatively, if we see the misconfiguration essentially eradicated from the observable npm universe before then, maybe it will approachable.
Feel free to get started 😄
[
  'tslib',
  'yargs',
  'socket.io',
  'acorn',
  'eventemitter3',
  'socket.io-client',
  'sequelize',
  'colorette',
  'concurrently',
  'react-select',
  'isomorphic-unfetch',
  'regexpp',
  'csv',
  'is-promise',
  'zod',
  'react-inspector',
  'listr2',
  '@storybook/react',
  'cypress',
  '@storybook/addons',
  'acorn-walk',
  'cjs-module-lexer',
  '@storybook/theming',
  'react-toastify',
  '@storybook/csf',
  '@storybook/core-events',
  '@storybook/api',
  'geolib',
  'dexie',
  '@storybook/client-logger',
  'discord-api-types',
  'ngx-bootstrap',
  '@storybook/addon-actions',
  'sqlite',
  'vue-demi',
  'markdown-to-jsx',
  'deep-object-diff',
  '@storybook/channels',
  '@fortawesome/fontawesome-svg-core',
  '@fortawesome/free-solid-svg-icons',
  'pathe',
  'hls.js',
  '@storybook/store',
  '@storybook/router',
  'react-merge-refs',
  '@storybook/core-common',
  '@storybook/docs-tools',
  '@headlessui/react',
  '@storybook/preview-web',
  '@discordjs/builders',
  'preact-render-to-string',
  'lmdb',
  '@storybook/cli',
  '@storybook/addon-essentials',
  'is-what',
  '@storybook/channel-websocket',
  'favicons',
  '@storybook/builder-webpack5',
  'async-mutex',
  'copy-anything',
  '@storybook/telemetry',
  'amqp-connection-manager',
  '@discordjs/rest',
  'parse-duration',
  '@storybook/components',
  '@storybook/addon-outline',
  '@storybook/addon-interactions',
  '@storybook/addon-measure',
  '@storybook/addon-links',
  'react-idle-timer',
  '@discordjs/collection',
  '@solana/spl-token',
  '@storybook/addon-toolbars',
  'msgpackr',
  '@storybook/addon-docs',
  '@urql/core'
]

Interesting that quite a few are in the storybook org. I wonder getting buy-in from that org and fixing it there would be a good first step.

Not exactly how I've imagined my weekend... but PRs to all* the repos from the list are up by now 😉 That series of PRs mainly focuses on fixing the "🐛 Used fallback condition" problem. Many packages are broken with "🎭 Masquerading as CJS" but some also with "🚭 Unexpected ESM syntax", "👺 Masquerading as ESM" and "⚠ ESM (dynamic import only)". I mentioned those problems in most of my PRs (when applicable).
*for one I opened an issue instead of a PR

The detectable occurrence of this problem in the top ~5k npm packages is down to 14 packages:
[
  'yargs',
  'acorn',
  'highlight.js',
  'sequelize',
  'colorette',
  'concurrently',
  'isomorphic-unfetch',
  'regexpp',
  'react-inspector',
  'is-promise',
  'acorn-walk',
  'cjs-module-lexer',
  'zod',
  '@storybook/csf'
]

Impressive work, @Andarist

Some of the listed ones landed the fixes for this. I’ll take around across them to recheck their release statuses and gonna get back here with a 1 by 1 breakdown

Ooooh, my bad 😬 There was a bug in my script and that’s not the whole list. There are actually 29:
[
  'yargs',
  'acorn',
  'sequelize',
  'highlight.js',
  'colorette',
  'concurrently',
  'isomorphic-unfetch',
  'is-promise',
  'zod',
  'regexpp',
  'react-inspector',
  'acorn-walk',
  'cjs-module-lexer',
  '@storybook/csf',
  'geolib',
  '@fortawesome/fontawesome-svg-core',
  'ngx-bootstrap',
  'markdown-to-jsx',
  'deep-object-diff',
  '@fortawesome/free-solid-svg-icons',
  'pathe',
  '@headlessui/react',
  'async-mutex',
  'parse-duration',
  'favicons',
  'antlr4',
  'check-disk-space',
  'react-idle-timer',
  '@solana/spl-token'
]

Still amazing progress! 😅

package
status

yargs
approved but not merged https://github.com/yargs/yargs/pull/2327

acorn
merged but not released

sequelize
merged but not released but the fix got merged into their v7 alpha that also renames the package, prepared a new PR that targets the current latest release: https://github.com/sequelize/sequelize/pull/16085

highlight.js
this wasn't on the original list, the issue itself was merged on Mar 19: https://github.com/highlightjs/highlight.js/pull/3736 , prepared a fix for it: https://github.com/highlightjs/highlight.js/pull/3800

colorette
merged but not released

concurrently
merged but not released

isomorphic-unfetch
no response in the PR, it's developit's (Jason Miller, Preact's author) package. He is busy and didn't see the PR - it's likely that we could get his attention on this using other channels

is-promise
no response in the PR

zod
merged but not released

regexpp
no response in the PR, it's likely that this won't be addressed. There is a community fork of this package (@eslint-community/regexpp) and the issue is fixed there.

react-inspector
merged but not released

acorn-walk
merged but not released

cjs-module-lexer
merged but not released

@storybook/csf
I missed this initially because it's a @storybook/* package but yet it's not in their monorepo. Prepared PRs to fix this right now

geolib
merged but not released

@fortawesome/fontawesome-svg-core
2 weeks ago I got an info that the issue was fixed (here) and that it should go out in the next release. There was no new release yet though.

@fortawesome/free-solid-svg-icons
same as above

ngx-bootstrap
I couldn't fix this easily because it's an Angular project and it's using a lot of indirection to generate their packages. I created an issue about this but didn't get any response so far. I think that's actually an issue with the lib builder that they are using (ng-packagr) but couldn't yet find the solution for it. Note that this package is just plainly broken - package.json#exports.types are pointing to files that don't exist. The intention was clearly for them to exist but for some reason those files are not generated. So it's a pure luck that it manages to fall back to types through other lookup mechanisms

markdown-to-js
merged but not released

deep-object-diff
no response in the PR

pathe
merged but not released

@headlessui/react
merged but not released

async-mutex
no response in the PR

parse-duration
merged but not released

favicons
merged but not released

antlr4
this wasn't on the original list, the issue was created on Apr 13: https://github.com/antlr/antlr4/commit/a9e697813c2dc1f182aea9d9c00691d05ab6f5fe , prepared a fix for it: https://github.com/antlr/antlr4/pull/4297

check-disk-space
this wasn't on the original list, the issue was created on Apr 20: https://github.com/Alex-D/check-disk-space/commit/2a95bf8d7e5b6a7e9a0be73d17af383ae729d2f2 , prepared a fix for it: https://github.com/Alex-D/check-disk-space/pull/28

react-idle-timer
soft-approved but not merged https://github.com/SupremeTechnopriest/react-idle-timer/pull/343

@solana/spl-token
merged but not released


Add camera locked / unlocked into RequiredState

Camera should get unlocked at the end of chapter 1, so it'd be nice to have that boolean on the required state.

Done in #252


unexpected decrement of variable higher in the call stack

I am running:
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.3
BuildVersion:   18D109

$ java -version
java version "1.8.0_212"
Java(TM) SE Runtime Environment (build 1.8.0_212-b31)
Java HotSpot(TM) GraalVM EE 19.0.1 (build 25.212-b31-jvmci-19-b01, mixed mode)

$ which node
/Library/Java/JavaVirtualMachines/graalvm-ee-19.0.1/Contents/Home/bin/node

I have a unit test calling a module exported method here where the method has a pretty simple loop:
  for ( i = 0; i < secret.length; i++ ){
    console.log("before i:"+ i + " "+  secret.length);
    const p = GF256.generate(randomBytes, k - 1, secret[0]);
    console.log("after i:"+ i + " "+ secret.length);
  }

The logic should be looping over the array secret but I removed passing i into the method call as it appears to get corrupted. The method call to GF256.generate resets i to 0. So the unit test loops forever until you ctrl+c it. You can see this behaviour by checking out the branch then at the top level run:
node src/test/js/SchemeTests.js

The first 15 lines are something like:
TAP version 13
# SchemeTests roundtrip
n:3, k:2 secret.length:3
before i:0 3
after  i:1 3
before i:2 3
after  i:1 3
before i:2 3
after  i:1 3
before i:2 3
after  i:1 3
before i:2 3
after  i:1 3
before i:2 3
after  i:1 3

I cannot see how i is getting assigned back to 1 in this code. I am thinking it might be a bug in graaljs

Note that your for loop (for ( i = 0; i < secret.length; i++ ){) is using a global variable i. This is not a good idea. Some other loops in your code are using the same global variable as well (namely degree function in GF256.js). Loops of this kind do not work when one is invoked from another. In other words, i is decreased by the mentioned degree function. So, the infinite loop is not a bug of GraalVM JavaScript engine. I suggest you to use function or block scope variables in your loops, i.e., use for (var i=0; ... or for (let i=0; ... instead of for (i=0; ....

thanks! i have added "use strict" to the files which to stop the code from compiling while accidentally using undeclared globals.


Add ParallelAgent class

Issue number: N/A
Summary
Current version of the multi-agent-orchestrator package does not have any readily available agents to run concurrent operations across multiple agents. Default agents either run independently or need to be sequentially linked with a ChainAgent.  A new ParallelAgent that allows multiple agents to run simultaneously would allow for more efficient runtimes and more advanced agentic designs.
Changes
New ParallelAgent module has been added by adapting some of the core logic from ChainAgent. Minimal use of external packages (only typing and asyncio as additional imports beyond modules in the src code).  Asynchronously and simultaneously runs each individual agent provided to ParallelAgent, then outputting result as ConversationMessage class.  The individual agents within the overall ParallelAgent can be of any default agent class. The combined response from all agents within the ParallelAgent is embedded in the ConversationMessage as a dictionary with agent names in keys and text responses as values.
Possible next steps:

Finalize python implementation of ParallelAgent
Replicate logic to TypeScript
Update documentation/website (mirror ChainAgent info on main package website)
Anything else suggested by package authors/maintainers

User experience
Users would be able to import and use the ParallelAgent class in a similar manner as ChainAgent.
Checklist
If your change doesn't seem to apply, please leave them unchecked.

[X] I have performed a self-review of this change
[X] Changes have been tested
[X] Changes are documented

Is this a breaking change?
RFC issue number: N/A
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

@carr324 Please review the suggested code if it makes sense (powered by Sonnet 3.5 :) )

@brnaba-aws  Thanks for the code!  Generally looks good, although haven't had a chance to test/debug the new version. Seems to follow the logic pretty closely, and I like some of the streamlining improvements.  Couple quick thoughts below.  LMK preferred next steps:

Any particular reason to use dataclass for ParallelAgentOptions?  Might be best to match format used elsewhere in the codebase.
Need to change _get_llm_response to _get_agent_response and remove LLM-specific mentions
Should static/internal methods match format of other agent types? (e.g., ChainAgent)
Suggest maintaining the newest generic type hints used in the original code, rather than the typing module used more widely in this version (https://medium.com/@onurbaskin/did-you-know-some-types-in-pythons-typing-module-are-now-deprecated-551ab9ac1ba1)

@brnaba-aws See link here for a scrappy example of LLM-as-a-judge-style implementation for sentiment analysis on social media posts: https://github.com/carr324/multi-agent-orchestrator/tree/parallel-agent/examples/parallel-chain-agent

3 individual analyzer agents are given the same sentiment analysis prompt, which is updated with an input thread of social media posts
All analyzer agents are used to create a ParallelAgent
A final judge agent is created & updated with its own system prompt (using the same input posts)
The ParallelAgent (step 1) + judge agent (step 2) are added to a ChainAgent which takes care of the overall flow
ChainAgent is added to orchestrator and used to respond to request

These files are simplified versions of a more advanced package I created, but seems to run fine on my end.  LMK if you if you have any thoughts/suggestions (or notice anything off in my creation of these new files/examples).
Thanks!

Updated parallel_agent module and example files with the version that uses concurrent.futures, after testing my @brnaba-aws .


ERROR: "No torrent client configuration specified in the config file."

Config:
{
  "red_key": "XXX",
  "ops_key": "YYY",
  "qbittorrent_url": "http://localhost:8090",
  "inject_torrents": true,
  "injection_link_directory": "H:/torrents/links"

}

Command:
python main.py -i "C:/Users/Tordenflesk/AppData/Local/qBittorrent/BT_backup" -o "H:/Torrents/Watch/_MUSIC.cross-seed"

That's my bad - I updated the docs but decided I wanted to let my testing run overnight before publishing the new changes.
I've just pushed up v0.0.7 that includes qbit injection support 🤙

Also just FYI I only recommend torrent injection for Docker users (as mentioned in the docs). You do you, but it hasn't been tested on bare Windows whatsoever


goxc build vars are quoted

On the status page, rc1 has: '1.1.0-rc1', built on '2016-03-03T21:46:41-08:00'
There should not be single quotes around the version and date - goxc appears to be linking that in.

Turns out this is a goxc bug: https://github.com/laher/goxc/issues/91

Fixed in https://github.com/laher/goxc/pull/92


ENH: add the parameter dropna to the function to_dict.

this is usefull because you cant reach the same effect by just using
dropna().to_dict() also see
http://stackoverflow.com/questions/26033301/make-pandas-dataframe-to-a-dict-and-dropna/26033302#26033302

closing pls reopen if/when updated

@derDieDasJojo if you would update, I think using a na_rep makes it a bit more generally useful.


Fixing CLI command for docker-compose in docker deployment Docs

The shell command for docker-compose on linux / windows is one word with a hyphen tweaking the example to work without modifications
Not sure if there is a particular branch or tag to give for documentation updates but it is a 2 character fix so I don't want to overthink it.

Wondering if we should add a call out about that to the document? just add a small sentence after the requirement of docker compose 2+?

@svrnm it is already there: https://opentelemetry.io/docs/demo/docker-deployment/#prerequisites

@svrnm it is already there: https://opentelemetry.io/docs/demo/docker-deployment/#prerequisites

What I meant was something like
## Prerequisites

- Docker
- [Docker Compose](https://docs.docker.com/compose/install/#install-compose)
  v2.0.0+ (Note: if you are using `docker-compose` you still use v1 and need to upgrade)
- 4 GB of RAM for the application

Ah I see. Yeah, I don't think that would hurt 😅

@svrnm et al.: Might it make sense to uniformly use docker compose throughout the docs? Doing a quick search, this is how it currently looks:
# opentelemetry.io
$ find . -type f -name "*.md" -path "./content/*" -exec grep -nH -e 'docker-compose ' {} +
./content/en/docs/collector/getting-started.md:21:  docker-compose up -d
./content/en/blog/2022/apisix/index.md:194:The following uses docker-compose as an example. For other deployments, see
./content/en/blog/2022/apisix/index.md:202:docker-compose up -d
./content/en/blog/2022/debug-otel-with-otel/index.md:140:Spin up that environment by running `docker-compose up` and send some requests
./content/en/blog/2022/debug-otel-with-otel/index.md:202:Once again we ran `docker-compose up` to bring up our sample app and we send
./content/en/blog/2022/instrument-apache-httpd-server/index.md:30:docker-compose --profile centos7 build
./content/en/blog/2022/instrument-apache-httpd-server/index.md:42:docker-compose --profile centos7 up -d
./content/en/blog/2022/instrument-apache-httpd-server/index.md:158:  docker-compose --profile centos7 build
./content/en/blog/2022/instrument-nginx/index.md:171:$ docker-compose up
./content/en/blog/2022/instrument-nginx/index.md:335:$ docker-compose up
./content/en/blog/2023/end-user-q-and-a-02.md:249:example, for a Ruby developer, clone X repo, run `docker-compose up`, and
$ find . -type f -name "*.md" -path "./content/*" -exec grep -nH -e 'docker-compose ' {} + | wc -l
      11
$ find . -type f -name "*.md" -path "./content/*" -exec grep -nH -e 'docker.compose ' {} + | wc -l
      19

Also ill need to double check which version of docker that gets introduced on, I was running it on Debian 11 with whatever the latest docker package in the the standard repository is so fair game if it needs to be the community edition and I am just behind the times, I should rtfm and put that version that was in the docs on.
If it is just me being a dolt, fair game

I created #2717 to solve this consistently. Tbh, I don't have a good answer for it yet.
Thank you for bringing this to our attention @CoryBarney

Golden, thanks for putting up my shenanigans.
I'll close this PR if there is no need for it then

Golden, thanks for putting up my shenanigans.

Thank you for bringing this to our attention, even if we can not provide a good solution right now ;-)

I'll close this PR if there is no need for it then

Yes, let's close it for now


Update CI for SGX SDK action update

Also update the rust toolchain action to https://github.com/dtolnay/rust-toolchain

Motivation

Future Work

Current dependencies on/for this PR:

main

PR #14   👈

This comment was auto-generated by Graphite.


Add missing client routes

Add missing client routes mentionned in #75 .
Tested on the local API.
closes #75
NB: the media is not yet uploaded as we don't have included the Qarnot computing bucket service.

For the sake of adding unittests in the same PR, perhaps let's first merge #74 before this one

The client methods I added are "post" routes. Did you find a way to unit test the post routes?

Thanks for the PR ! I am trying to test it locally, and I have so far some issues (but it could came from my understanding :))
Have tested all the new methods  ?
Also, I have jsute noticed, the heartbeat method is actually called "hearbeat" , I think this is just typo but we can correct it in the PR :)

Yes I tested it locally; the client need to be logged as a device though.

The client methods I added are "post" routes. Did you find a way to unit test the post routes?

Good point, so far we haven't solved that, so I guess we can do that later on!


Improve supply chain security

[ ] use Harden Runner in all GH workflows
[ ] use hashes instead of versions in GH workflows
[ ] add OpenSSF Scorecard GH workflow to identify issues
[ ] use cosigner to sign docker image via GH action
[ ] use dependency-review GH action
[ ] add security.md with contact details

I found some nice examples in https://github.com/sozercan/aikit/tree/main/.github/workflows
Not related to supply chain security but code quality

[ ] add codeql GH action
[ ] add linter GH action

I'm all for security improvements, but at the same need to ensure that:

doesn't make it more painful to do releases and development on the project
doesn't hurt the UX
doesn't significantly increase complexity

I think all of your tasks make sense, except Harden Runner might make adding and updating GH workflows a bit more painful, but at the same time it does seem good to prevent malicious PRs as well.


js.Build unable to resolve file in data directory

The intended behavior may have changed at some point, but our documentation states:

Any imports in a file outside /assets or that does not resolve to a component inside /assets will be resolved by ESBuild with the project directory as the resolve directory (used as the starting point when looking for node_modules etc.)

assets/
├── js/
│   └── main.js
└── jsconfig.json
data/
└── data.json

assets/js/main.js
import data from "../../data/data.json";

There no directory mounts in site config (default mounts).
This stopped working in v0.78.1.
It may just be a documentation issue.

So, the documentation is correct, I guess, but you need to look in ESBuild's documentation to see where that library looks for stuff. And my guess that's limited to what package.json says. If it worked before, it may be an upstream issue, but I would recommend to stick to either node_modules or assets.

Yeah, I ran across this while verifying that https://github.com/gohugoio/hugo/issues/7544 will be resolved by https://github.com/gohugoio/hugo/pull/11894, but I was unable to reproduce the setup due to this (11898) issue.
I'm going to close this, and will add a comment to 7544 to indicate the correct approach. The OP in 7544 wanted to access data.json from both JS (esBuild) and site.Data.data.foo, which should be handled with a mount.
[[module.mounts]]
source = 'assets'
target = 'assets'

[[module.mounts]]
source = 'data'
target = 'assets/data'

Then in main.js
import data from "data/data.json";
console.log(data.foo);


Supplier declaration

https://www.pivotaltracker.com/story/show/100215022
This wires up the dummy supplier declaration page with real questions and makes use of the content loader.
This change also makes use of form parsing code that has now moved into dmutils (https://github.com/alphagov/digitalmarketplace-utils/pull/126).
Validation and reporting on whether the declaration is complete is part of another story (https://www.pivotaltracker.com/story/show/100215328).

This should probably redirect to the dashboard page when you save.

:+1:


Update Stream.php

Fix the seek method in League\Csv\Stream.php. If the $position parameter is 0, $offset will become -1.

could you:

add the tests in StreamTest.php and then I'll merge it
use Yoda style in the if condition
and I'll merge your fix

thanks in advance


Update point-in-time-restore-overview.md

feedback from support to make it clear that registration is automatic

@klaaslanghout : Thanks for your contribution! The author(s) have been notified to review your proposed change.


BIP Installation of Preview / Stable 2.0 version

I tried to deploy the Preview (and the stable) 2.0 version through "Tools -> Platform extensions" and received an error message for Shared:

!ENTRY com.sap.ip.bi.zen.ui 4 0 2015-06-17 14:15:15.776
 !MESSAGE One or more extensions failed to install
 !STACK 0
 com.sap.ip.bi.zen.connectivity.ConnectivityException: Failed to access plugin JAR file of extension "Design Studio SCN Community Shared" (id: org.scn.community.shared)
at com.sap.ip.bi.zen.backends.bip.BiPlatformSystem.deployExtensions(BiPlatformSystem.java:2303)
at com.sap.ip.bi.zen.ui.internal.dialogs.sdk.PlatformExtensionsDialog.installExtensions(PlatformExtensionsDialog.java:278) ...

I'll try to debug it but, in the mean time, if you have a clue :)
Platform: BIP 4.1 SP5
DS 1.5

Just following up.
I noticed something "Stange":

As you can see, all plugins are in a jar file, except for Shared, just after the installation in DS 1.5.
Even weirder:

Copying / creating a jar Shared file does not fix the Platform installation issue
Deleting the Shared folder and leaving the jar works on local (as expected), but the Shared components are not deployable on BIP anymore

I've not downloaded the newest sources yet, however I'm going to guess that
Karol may have accidentally left 'Unpack the plug-in archive after the
installation' checked in the feature project.  I know that if you
accidentally do this, it will run in client mode but will not deploy to
server.  Also, you'll have unpacked jars in your plugins directory as
you've shown above.
On Wed, Jun 17, 2015 at 9:55 AM, franckblais<EMAIL_ADDRESS>wrote:

Just following up.
I noticed something "Stange":
[image: image]
https://cloud.githubusercontent.com/assets/10117707/8210237/0cfc7bf0-14df-11e5-9a68-369bcee1305f.png
As you can see, all plugins are in a jar file, except for Shared, just
after the installation in DS 1.5.
Even weirder:

Copying / creating a jar Shared file does not fix the Platform
installation issue

Deleting the Shared folder and leaving the jar works on local (as
expected), but the Shared components are not deployable on BIP anymore

—
Reply to this email directly or view it on GitHub
https://github.com/org-scn-design-studio-community/sdkpackage/issues/53#issuecomment-112831385
.

--
Mike Howles

Mmmhhh,
I check the feature.xml in the archive (same behaviour with archive/update site)

Seems it's unchecked.

Interesting!  I'm out of ideas at the moment then...
On Wed, Jun 17, 2015 at 10:17 AM, franckblais<EMAIL_ADDRESS>wrote:

Mmmhhh,
I check the feature.xml in the archive (same behaviour with archive/update
site)
[image: image]
https://cloud.githubusercontent.com/assets/10117707/8210932/6b2b225a-14e2-11e5-8d8e-5e28a750aa99.png
Seems it's unchecked.
—
Reply to this email directly or view it on GitHub
https://github.com/org-scn-design-studio-community/sdkpackage/issues/53#issuecomment-112840583
.

--
Mike Howles

It's too bad: seemed tho be the issue !

So, yes, the Shared component is installed decompressed:

As we can see, when installing, the .jar is missing (but it's working in local).
I searched a bit on SCN but no real answer could be found, and I am too newb to find out something in the xml files ...
I tried to clean my DS and reinstall, same error.

Thanks Mike !
You're right ... Checked in Datasource. Have you rebuild the project ?
Thanks again ! :)

fixed already by Mike. closing it.


Support for case sensitive indexes

Is there a way to have case-sensitive indexes within Hugo?  There's a comment at https://github.com/spf13/hugo/blob/master/hugolib/index.go#L60 that indicates that it could be possible someday.
It would be great to create categories that are case (and space) sensitive.
---
categories:
  - Introductory Text
  - Help Notes
---

And be able to list them so that they keep the original formatting.
{{ range .Site.Indexes.categories.ByCount }}
<li>{{ .Name }}</li>
{{ end }}

What would need to be done to accomplish this?

Set
preservetaxonomynames: true

in config. And the indexes will be, among other things, case sensitive.


Setting max level option does not have any effect

If I set/change the option for max_level, no any change in the displaying.

Sure, sorry.
Here is my config:
type: custom:rain-gauge-card
entity: sensor.rain_24h
show_warning: false
show_error: false
is_imperial: false
max_level: 3
What I get is:

According to my understanding the level should be around 1/3 of the total height, right?
If I change the max_level to 2, nothing changes in the displaying, however it should be about 1/2 of the total height with the actual value of 1.1.

@tanker11 I've set the minimum to be 40mm so if the max_level is anything below this then it will not take this into account.
But if you set this anything above then it will work.
I just wanted to be defensive within the code.

Okay, noted. :)
It is a pity, because in my country a typical value is much less, so it
would rarely show bigger amounts than something in the bottom of the drop
then...
I will not remarkably see the difference between 2 and 5mm.
Anyway, thanks for the clarification.
Marc Sygrove @.***> ezt írta (időpont: 2023. máj. 16.,
K, 15:26):

@tanker11 https://github.com/tanker11 I've set the minimum to be 40mm
so if the max_level is anything below this then it will not take this
into account.
But if you set this anything above then it will work.
I just wanted to be defensive within the code.
—
Reply to this email directly, view it on GitHub
https://github.com/t1gr0u/rain-gauge-card/issues/16#issuecomment-1549674850,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHVM6O5NWX24WPKK64CKLL3XGN577ANCNFSM6AAAAAAYCN7J4Y
.
You are receiving this because you were mentioned.Message ID:
@.***>

If I get more requests to drop the minimum (40mm) then I would consider it :)

Ok, thanks for that.
Marc Sygrove @.***> ezt írta (időpont: 2023. máj. 16.,
Ke 15:36):

If I get more requests to drop the minimum (40mm) then I would consider it
:)
—
Reply to this email directly, view it on GitHub
https://github.com/t1gr0u/rain-gauge-card/issues/16#issuecomment-1549689953,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHVM6O6IBNA6U47ZRC2ZJPDXGN7FRANCNFSM6AAAAAAYCN7J4Y
.
You are receiving this because you were mentioned.Message ID:
@.***>

+1
Maby let oss be able set the minimum value.

I'd like to leave a +1 for this change too.....IMHO 40mm is excessive as a min level for the Gauge.
As example almost biblical rain yesterday here (Ireland) but still only hitting 27mm of rain in 24 hours.....going back over past 12 months the max daily rain here was 37mm......not sure where dev is from so maybe 40mm+ daily is usual (tho you're UK I think so unlikely)....anyway just my thoughts.....

It works of i set is-imperial to true.
But it would be nice if this works with mm as well.
type: custom:rain-gauge-card
language: de
name: Regen
show_error: false
show_warning: false
entity: sensor.innen_innen_innen_regen_pws_rain_today
hourly_rate_entity: sensor.innen_innen_innen_regen_pws_rain
is_imperial: true
max_level: '8'

@tanker11 this is now fixed in v1.4.0, thank you for using this card.


Run Langsmith Evals

Two steps to run (after getting a Langsmith API Key)

Upload dataset (currently just using the existing benchmark)

python langsmith_evals --action upload

Run eval

python langsmith_evals --path-to-agent gpt_engineer/core/default/simple_agent.py

Results example: https://smith.langchain.com/public/21c3303f-a093-4e0d-984b-6a4d810c9af5/d

Awesome
Thanks @hinthornw
Would love to have this merged but for code benchmarks in general, gpteng benchmarks are not that general

Awesome
Thanks @hinthornw
Would love to have this merged but for code benchmarks in general, gpteng benchmarks are not that general

Looks like you've got a ticket or two to check out (sampled) versions of the the APPS or mbpp datasets: I could add those if you haven't checked them out yet

@hinthornw that would be really cool! I know @pbharrin made this initial parsing of MBPP and APPS: https://github.com/pbharrin/gpt-engineer/commit/850a0d8dfe1130e117a150a475a8fd98a386b78e
Maybe this could be used.
A possibly practical way to add the data could be to add the respective github repos as submodules:
https://github.com/hendrycks/apps
https://github.com/google-research/google-research/tree/master/mbpp

Again would be great with those datasets and I think we could make it nice with custom evaluators
https://python.langchain.com/docs/guides/evaluation/string/custom
Would need a PoC for us to want to replace current benchmark logic (which is quite simple) though
Letting you know @hinthornw in case you or teammate have time to check if langchain eval can be made nice to work with for codegen!

Closing this PR but feel free to reopen @hinthornw !

Again would be great with those datasets and I think we could make it nice with custom evaluators
https://python.langchain.com/docs/guides/evaluation/string/custom
Letting you know @hinthornw in case you or teammate have time to check if langchain eval can be made nice to work with for codegen as a PoC, by being able to cover for the current benchmark system in benchmark folder!


Add support for aws sdk 22

The new sdk has some nice improvements to take advantage of, specially around error handling.
Created a PR - not sure if there's some additional changes needed for testing but the build works.
https://github.com/zenlist/serde_dynamo/pull/56/

Closed by #56


Any reason you're using underscore instead of lodash?

Lodash is faster / more optimized than underscore, any reason you guys aren't using it?

i think  still underscore is used is there a plan for switch?


Migrated all of Contributing

from cwiki.apache.org/confluence/display/WAVE to the reST text format. Images were also transferred. Minor text/spelling changes made, most text copied as collected.

LGTM.


Add Bootstrap 4-alpha to NPM registry

Hi,
Any plans to make 4.0.0-alpha available in the npm registry?

@ryzy npm install https://github.com/twbs/bootstrap.git#v4-dev

We'll publish the next alpha version (v4.0.0-alpha.2) when it gets released.

Any word on when alpha 2 is going to be released to NPM? Thanks!

Due to the strict release cycle as described in the blog post for alpha 1 the core team is focusing on a longer beta for the first alpha or two to ensure that as many bugs as possible are caught in each release and Bootstrap 4 isn't rushed out with bugs. At this point, no date is publicly announced to my knowledge for any future release (alpha, beta or production)

:+1: okay cool. thanks for the update.

@cvrebert Do you all still plan to add v4.0.0-alpha.2 to npm now that it's been released?

@schnerd It's already on npm. See #18520.

Awesome–thanks. Was expecting a different package for some reason.


Support selection does not work when a friend has not set any support Servants

If you have friends with newer players, this is a problem since the scrip will just stop if out of nowhere if one of them shows up on the top of the screen like this when the scrip is selecting a support servant.
All the scrip will do is just click on the gray part on the left until the player/user click on a servant manually.
Is there any way where you can tell the scrip to ignore the grey part or check to see if it's says "Servant: Not Set" and then go to the one below it when choosing a support servant.

Are you running the latest commit?
In #335, @TryBane changed support_region_tool.png from this:

To this:

So it should work, I guess.

Are you running the latest commit?

I was using the "Merge pull request #343 from reconman/fix-debug-option" one before now.

What's the option you're using? preferred or first?

Are you taking about the lua scrips? if then so, then i'm just using the default settings.

This is due to the script can not find a friend support on the first screenshot, it will stop there instead of trying to scroll and find one.
In selectPreferred, change the code to:
if result == "ok" then
			click(support)
			return true

		elseif result ~= "ok" and numberOfSwipes < Support_SwipesPerUpdate then
			scrollList()
			numberOfSwipes = numberOfSwipes + 1
			wait(0.3)

should fix this


[REQUEST] Integrate Achievement Watcher

Is your feature request related to a problem? Please describe.
Currently, Hydra Launcher excels at organizing and managing game downloads and installations, but it lacks a comprehensive achievement tracking system. Many gamers appreciate tracking their in-game achievements as it adds to the overall gaming experience and provides a sense of accomplishment. Without this feature, users need to rely on separate applications or manual tracking, which can be cumbersome and disrupt the seamless experience Hydra aims to provide.
Describe the solution you'd like
I propose integrating Achievement Watcher into Hydra Launcher. Achievement Watcher is an achievement tracking tool that supports multiple game platforms, including Steam and Steam emulators. By embedding Achievement Watcher into Hydra, users would receive real-time notifications of their achievements, along with automatic screenshots or video captures of those moments. This integration would enhance the gaming experience by consolidating all relevant game-related information and milestones within Hydra.
Describe alternatives you've considered
Manual Tracking: Users manually track their achievements using spreadsheets or notes, which is inconvenient and lacks the real-time engagement.
Third-party Applications: Users can install and run Achievement Watcher separately, but this adds complexity and fragments the gaming experience between multiple applications.
Built-in Basic Achievement Tracking: Hydra could develop its basic achievement tracking system, but it would likely be less comprehensive and robust compared to the well-established Achievement Watcher.
Additional context
User Engagement: Integrating Achievement Watcher can increase user engagement by making Hydra a one-stop hub for game management and achievement tracking.
Community Feedback: Many users in gaming forums and communities have expressed the desire for integrated achievement tracking within their game launchers like Playnite.
Technical Feasibility: Achievement Watcher is open-source and can be integrated with proper API usage and collaboration with its developers.
Enhanced Experience: Real-time notifications, coupled with automatic screenshots and videos, provide a richer and more interactive gaming experience.

implemented in update 3.0.


Adds scan support

Exposes api for scan
https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/scan.md

Thanks!
That is the difference with the already existing reduce function?

Oh, I know! Nice work!

The differences is that reduce only returns 1 value but scan reduces all the intermediate values.


Unreliable EnTypeCheck

Steps to reproduce

git clone https://github.com/fhnw-saav/saav
sbt ensimeConfig
vim src/main/scala/ch/fhnw/ima/saav/MainApp.scala
:EnTypeCheck
:EnTypeCheck

Expected behaviour
Step 4 should kick off type checking, resulting in error highlights.
Actual behaviour
Step 4 completes immediately and does not highlight errors:
[ensime] Typechecking...
Press ENTER or type command to continue

After another invocation (step 5), everything works as expected (an error on line 62).
ensime-vim-log.txt

It seems you are trying to type-check before the server is ready. Please wait until you see the message from the server when it's ready in the status bar, then trigger the check. That should give you the expected behaviour.

I see [ensime] Server has been started... pretty much immediately. Still it takes two or more EnTypeCheck invocations to get an actual type check.
Attached another log, hope it helps...
ensime-vim-log.txt

Just made a weird observation:
Inside VIM, when I type ":EnType" and then press the tab key until "EnTypeCheck" is focused, and then press return, the type checking always completes immediately and no errors are highlighted.
However, when I type in the full ":EnTypeCheck" command character after character, it always works.
Maybe "correlation is not causation", but it was 100% reproducible when I tried 5x in a row 😕

I see [ensime] Server has been started... pretty much immediately. Still it takes two or more EnTypeCheck invocations to get an actual type check.

Sorry for the delay in responding, but this message doesn't mean the server is ready, there are two subsequent messages, "Indexer is ready" and "Analyzer is ready"—effectively you'll want to wait for both of these before you can expect the plugin to be fully functional and stable.
I'm sure we could stand to improve the messaging/behavior when user acts before the server is ready, but for now this is "working as intended" if you find that your issue isn't reproducible after waiting.
If the problem still persists despite this, feel free to re-open. Or if it bothers you enough to want to take a shot at making the behavior better, opening a new enhancement issue for that would be great.


[ci] parallelize tox on gitlab & appveyor

What does this PR do?
This speeds up tox by ~50%.

There is a race condition when installing our datadog-checks-base. I'll investigate why eventually.


autoimmune retinopathy

From @mellybelly on September 11, 2017 21:50
we don't seem to have this as a disease, see for example:
http://www.ohsu.edu/xd/health/services/casey-eye/clinical-services/specialty-services/genetics/autoimmune-retinopathy.cfm
see also relationships to cancer described there.
There is also a patient group on Facebook: https://www.facebook.com/groups/AIRcommunity/
(we really should be working with Facebook....)
Copied from original issue: monarch-initiative/monarch-disease-ontology-RETIRED#391

@cmungall and @pnrobinson I added the new term MONDO_0100014  autoimmune retinopathy
In this article, they say there are three categories of autoimmune retinopathies:

paraneoplastic retinopathy, which includes recoverin-associated retinopathy and melanoma-associated retinopathy; we have this term (MONDO_0019112). Do you think I should make it a subclass of autoimmune retinopathy as well?
non-paraneoplastic autoimmune retinopathy- should I add this as a new class?
combined paraneoplastic optic neuropathy and retinopathy-  should I add this as a new class?

This paper describes 'melanoma-associated retinopathy', should I add this class as a subclass of MONDO_0019112 cancer-associated retinopathy (syn: paraneoplastic retinopathy)

This issue is 2.5 years old, I am going to assume this is no longer needed.


nothing provides kubernetes-cni needed by cri-o-1.28.1-150500.1.1.x86_64

When added the CRI-O repo as below:
[cri-o]
name=CRI-O
baseurl=https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.28/rpm/repodata/repomd.xml.key
I got the error message when execute the command yum install cri-o:
Importing GPG key 0x9A296436:
Userid     : "isv:kubernetes OBS Project<EMAIL_ADDRESS>Fingerprint: DE15 B144 86CD 377B 9E87 6E1A 2346 54DA 9A29 6436
From       : https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
Key imported successfully
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'yum clean packages'.
AlmaLinux 9 - AppStream                          59 MB/s |  11 MB     00:00
AlmaLinux 9 - BaseOS                             41 MB/s | 4.7 MB     00:00
AlmaLinux 9 - Extras                            201 kB/s |  18 kB     00:00
CRI-O                                           9.9 kB/s | 2.0 kB     00:00
Error:
Problem: cannot install the best candidate for the job

nothing provides kubernetes-cni needed by cri-o-1.28.1-150500.1.1.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Exited with code exit status 1

hm interesting the Recommends clause should mean it's not required

v1.28.1 is unfortunately broken, there is no stable release available yet via this repository. v1.28.2 will fix this.

Let’s keep it open to verify.

hm interesting the Recommends clause should mean it's not required

The "kubernetes-cni" package is provided by a different repository...
It was working in Fedora, due to a weird "Provides" on a system package:
containernetworking-plugins-1.1.1-16.fc38.x86_64 : Libraries for writing CNI plugin
Repo        : fedora
Matched from:
Provide    : kubernetes-cni

Which was unrelated anyway, since it provides /usr/lib/cni but not /opt/cni/bin.

Fixed in cri-o-1.29.0-150500.1.1.x86_64

Closing this one for https://github.com/cri-o/packaging/issues/68 and https://github.com/cri-o/packaging/issues/67


Consider add backpressure?

I am working with a sync socket stream based on c# .NET async socket but I find it will be some error of message dispatch when receive many msg form server at a time.
Does there consider add method backpressure?

It's my code error.I close it now, at least, I haven't find the function is must be require.


Group use declarations causes internal error

This is not working:
http://php.net/manual/en/language.namespaces.importing.php#language.namespaces.importing.group
"Files that were not fixed due to internal error"

Yes, these are known not to be supported by php-cs-fixer.

ref: #1119

They are listed in there as todo.

ping @jaszczurek the fixer should no longer run into an internal error, it might not fix the CS as you want yet. Could you give it another try?

@keradus this one can be closed, issue was fixed and no feedback from reporter

I think it's fixed indeed, sad we cannot get a confirmation from @jaszczurek .
Closing as fixed


Ghidra

where is Ghidra :)

In the backlog for the RE page. Until I get around to redoing that page, which should be soon, pull requests are appreciated.


Migrate the prometheus monitor to use pmetric data directly

This changes the prometheus-exporter monitor to directly convert data to pmetric data instead of datapoints, which are then converted to pmetric data. As result, the monitor uses less memory.

I think bypassing the sfx datapoint conversion removes support for the existing filtering logic and would be considered a breaking change. Can we do something like adding and documenting a new config option that defaults to false so this is opt in w/ known caveats?

We still can go a bit further on this one, and use the pprof extension to compare memory usage in tests. That would help test memory usage over time.

Some manual testing:
Before:
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O     PIDS
c592fe864131   otelcollector   182.82%   676.8MiB / 9.729GiB   6.79%     531MB / 1.31MB   65.5kB / 0B   14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O     PIDS
c592fe864131   otelcollector   137.58%   839.9MiB / 9.729GiB   8.43%     549MB / 1.37MB   65.5kB / 0B   14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O     PIDS
c592fe864131   otelcollector   137.58%   839.9MiB / 9.729GiB   8.43%     549MB / 1.37MB   65.5kB / 0B   14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O     PIDS
c592fe864131   otelcollector   152.88%   787.9MiB / 9.729GiB   7.91%     568MB / 1.44MB   65.5kB / 0B   14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O     PIDS
c592fe864131   otelcollector   152.88%   787.9MiB / 9.729GiB   7.91%     568MB / 1.44MB   65.5kB / 0B   14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O     PIDS
After:
b80982607e00   otelcollector   147.53%   108.6MiB / 9.729GiB   1.09%     585MB / 1.62MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   149.49%   119.2MiB / 9.729GiB   1.20%     605MB / 1.68MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   149.49%   119.2MiB / 9.729GiB   1.20%     605MB / 1.68MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   146.83%   128.2MiB / 9.729GiB   1.29%     625MB / 1.73MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   146.83%   128.2MiB / 9.729GiB   1.29%     625MB / 1.73MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   167.24%   308.5MiB / 9.729GiB   3.10%     636MB / 1.77MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   167.24%   308.5MiB / 9.729GiB   3.10%     636MB / 1.77MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   149.49%   223.2MiB / 9.729GiB   2.24%     655MB / 1.82MB   0B / 0B     14
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O   PIDS
b80982607e00   otelcollector   149.49%   223.2MiB / 9.729GiB   2.24%     655MB / 1.82MB   0B / 0B     14

OK, this is still very much WIP work, and I think I can peel off more things:

Make a separate PR for the integration test with filters (might test multiple filters)
Make a separate PR for filters with pmetric, to make the changes here a bit saner to review, and might need to introduce more test coverage to make sure we don't break anything
Add the output feature gate with pmetric vs datapoint for the prometheusexporter specifically.

Closing as old. We may want to delete more smart agent code to simplify this work.


(maint) Merge 5.5.x to 6.0.x

The commits check is failing because of (L10n) Updating translations for locales/ja/puppet.po. Can be safely ignored.

Waiting for CLA signature by @transifex-bot
@transifex-bot - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html

Does this need a second reviewer or are we good to go?

Well, thats answered. Thanks, folks.


SUB Day - Powerups

Add powerup locations to the map. Test that they all are working properly.

Spent 30 minutes setting up the powerups in the desired location


Perf/fix

Fix issues in previous FP8 measurements. Also add new FP8 GEMM with no overhead.

Close #17

Close #19
Close #18


OctopOS Prime Cutscene Animation Trial-1

OctopOS Prime runs, encounters obstacle, jumps over obstacle, he keeps running.

Divide the written animation topic into sections and work on team animation.

https://github.com/octoposprime/op-design/assets/135768038/4c00ca3f-840f-4450-bf7c-2189813828a3


Thanks

What feature or improvement would you like to see?
There are no issue yet, just thanks for the plugin working perfectly.
I will definitely become your patron subscriber as soon as I receive income from monetization.

@trash-max thank you very much! ❤


Integrate Nostr-Editor

Have the note creation to use nostr-editor, a set of nostr extension on top of the tiptap editor.
Bugs and known issue remaining:

The images are loaded and displayed inside the editor, as a result, the Compose component replace the ImageInput component. The goal is still to keep the underline carrousel, I miss a proper callback to get the uploaded image urls (onComplete not triggering)
When hitting Enter to select a mention, the editor does break the line, preventDefault does not help
tags or hashtags are immediately wrapped in  tags, it is underlined as you type before "space" key is hit
nostr-editor comes with a nostr event parsing. Images url are immediately set in the content and in the tags. We could potentially use this functionality entirely and remove internal logic from Coracle, but it depends how confident you are with this dependency.
Image urls are not in the tags when sending the event, this will be resolved

Took a lot from Flotilla in this commit.
Created a new folder "editor" under the app directory, like Flotilla, but with different Edit component. Let me know if you would rather have it somewhere else, or just add the Edit[whatever].svelte files in the shared directory.
‼NostrCreateInline and NostrReply still need to be adapted, the code break for any other url than notes/create. I still need to figure out the correct way to submit. For now it's weird, I upload the files and onSubmit() trigger in the onComplete callback of the file upload (kind of unrelated).

Any view that uses an editor will instantiate Editor with the correct parameters (essentially the session pubkey and eventual mentions)
Compose.svelte is still there atm, mostly for CSS purpose on the content of the editor (image blur-in blur-out while loaded)
Have to modify the uploadFile extension to store the files url being uploaded (to put them in the event tags)
Considering adding a small extension that will count words and characters being typed.
If we want to be close to a "live" note, I will support Spotify/Youtube/Github link with thumbnail eventually, this will not be a nostr extension but a slightly modified Media component

Great, looking good.

For now it's weird, I upload the files and onSubmit() trigger in the onComplete callback of the file upload (kind of unrelated).

Yeah, I think the reason it's this way is so that submit is deferred until files get uploaded. As a result, we currently have to defer uploading files until the user submits the form (which is a feature in a way, because it avoids them uploading files they don't ultimately want to use). I do think that uploading files concurrently for a quick submit is a better way to do this though, so hopefully we can find a way around this pattern.

Adapted NoteCreate, NoteReply, NoteCreateInline to use the new Compose element.
uploading all files before submitting at the moment. editor.commands.uploadFile re-upload all files in the editor atm. ImmediateUpload could be used too, but it does not trigger onComplete callback.
added iframes preview for YouTube and Twitter, the twitter preview is being blocked by plausible.io, you might be able to configure it there. If you validate, I'll add those preview to Media.svelte, so we get "native" preview for Tidal, Spotify, Youtube and Twitter.
WordCount extension to count characters and words.

Issues:

When opening/closing a reply, ie creating a draft, the editor will just render everything as text, haven't found how to force parse the content. Let me know if you know..

Added iframes preview for YouTube and Twitter, the twitter preview is being blocked by plausible.io, you might be able to configure it there. If you validate, I'll add those preview to Media.svelte, so we'll get a "native" preview for Tidal, Spotify, Youtube and Twitter.

That might be the content security policy, see frame-src in index.html.

When opening/closing a reply, ie creating a draft, the editor will just render everything as text, haven't found how to force parse the content. Do you know how to force it?

I've struggled with this as well. @cesardeazevedo, do you happen to know the solution to this?

What was the imeta tag used for and what are the parameters to it?

See here: https://github.com/nostr-protocol/nips/blob/07de7ea7e5d2934afac1eb86db0cd0a0200039a0/92.md?plain=1#L7

I haven't been able to figure out topics. I was able to avoid solving this in flotilla, but it does need to be done. Maybe ignore nostr-editors TagExtension and add a new Node type.

Not so sure about the actual issue here but the tag extension was very buggy before version 0.0.3.

Cesar and I had also talked about using tiptap to render notes. He was apparently able to get that working, but I've had some trouble.

I feel like the editor still struggles with things like hardbreak lines, I have found difficult to understand the correct approach.

I'm not sure it would be performant in practice

I would imagine the nostr-editor to be considerably slower than welshman/content (although would love to see some benchmarks), so use it with caution.

Have to modify the uploadFile extension to store the files url being uploaded (to put them in the event tags)

Nostr-editor indeed needs to provide an easy way to access the uploaded files, gonna work on that.

I miss a proper callback to get the uploaded image urls

This part indeed needs some improvement.

When opening/closing a reply, ie creating a draft, the editor will just render everything as text, haven't found how to force parse the content. Do you know how to force it?

Not so sure if I understood correctly, but you can't directly set a event content when initializing the editor
  const editor = useEditor({
    content: 'Hello nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccsqgxxvqas78x0a339m8qgkaf7fam5atmarne8dy3rzfd4l4x6w2qpncmfs8zh',
  })

This will render as text as tiptap won't apply any pasteRules here, I tried to find a way many times but couldn't, you have to call setEventContent manually.
  onCreate({ editor }) {
    editor.commands.setEventContent({
      id: '...',
      content: 'Hello nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccsqgxxvqas78x0a339m8qgkaf7fam5atmarne8dy3rzfd4l4x6w2qpncmfs8zh',
    })
  }

Interestingly you can set a HTML representation of the editor state, which is the content you get when copying the content directly from the editor (check the clipboard inspector)
  const editor = useEditor({
    content: `<meta charset='utf-8'>
@
`
  })

I've struggled with this as well. @cesardeazevedo, do you happen to know the solution to this?

It seems to be solved now by instantiating the editor with the content as HTML.

That might be the content security policy, see frame-src in index.html.

Have finally managed to have tweet preview working while keeping the content security policy, that's 2 twitter script tag, once being labelled with a git tag, but it works

Had to replicate the FileUpload extension, impossible to get the desired behaviour just by configuring it properly or via the callbacks provided. Might be worth a PR on Nostr-Editor.  Just added another command.getMetaTags()  that will give me the nip-94 image tags present in the note, as provided by the endpoint response. There was also an issue where the updated attributes (src, uploading etc) were placed on the wrong node,  this might be related to 2 extensions manipulating things at the same time.
I still want to test it with a blossom endpoint, do you know any?
The new editor has been replicated everywhere compose was used before, should we use it in channel as well?
Twitter and Youtube preview are now in the Media component, it shows up in the note feed basically
Images load immediately now, there is a blur-in blur-out animation while it loads. you might upload some image accidentally but submit is much faster.

Happy to get your feedback on the editor, until then I'll just keep merging dev and move on to other issues

thanks @cesardeazevedo for your answer !
I managed to have it all working well with file upload, I will keep testing and issue a PR on nostr-editor if needed.
I did have that strange issue where file attributes where not reported correctly when using immediate uploads, the examples on nostr-editor repo works as expected, but with the Coracle config, it consistently updated the wrong node, the one right before the actual Image node (pos - 1).

Might be worth a PR on Nostr-Editor.

Please do, it's worth having upstream.

I still want to test it with a blossom endpoint, do you know any?

Try https://blossom.hzrd149.com/

should we use it in channel as well?

Yeah, let's do it.
--
I'll test the PR, can you rebase from dev to fix the conflicts?

My understanding is that mod-enter is to submit, enter and shift-enter is for hardbreak. It is now the default configuration for the editor.

It is in a chat context, but it's actually the reverse when composing a note. Sort of weird, but seems the most intuitive.

 There are a whole bunch of changes from dev that are being merged back in here. When reconciling branches, try to always rebase rather than merge.

There are a whole bunch of changes from dev that are being merged back in here. When reconciling branches, try to always rebase rather than merge.

I rebased from origin/dev indeed, I had to go through twenty-ish commits cherrypicking the right changes, I might be doing something wrong, I'm not very used to rebase
Do you mean this PR is reversing some changes from dev?

It's the reverse, the diff is including changes that already exist on dev. This is likely due to me force-pushing to dev at some point in the past after a merge (which is why rebase works better). Try rebasing with -i and change pick to squash for all listed commits. That will give you a single commit to work with. Or check out a fresh copy of dev, then git reset feat/nostr-editor to pull your changes over without any history.

I'm happy to hop on a call and work on it with you if that would be helpful

Some display bugs and behavior issues:

Ctrl+enter doesn't submit the form on reply, but enter does. It should be the reverse
Nothing should render as a block, currently invoices, quotes, links do
link-content doesn't look as good as it does in flotilla. It should have some kind of background to it.
There are some weird artifacts with the mention suggestion dialog. Also, the size changes and the arrow moves, they should stay still.

Also, the PR needs a rebase. I ran one locally and it worked fine, so I think the reset did the trick.

reply now submit on mod+enter and not enter
Editor link, event, address and invoices render like in flotilla except the background is a different colour
The suggestions display used to be like flotilla (animation and so on), now it looks closer to Coracle, a lighter background for selected item, no animation.

reply now submit on mod+enter and not enter

The main note create should work the same way too, right now enter sends the note.
The popover looks better, but there's still this:

For blossom, try https://cdn.satellite.earth/, that one should work.

For blossom, try https://cdn.satellite.earth/, that one should work.
This one work, but you need to zap the server, the data is then kept for a month. This enpoint requires an additional size tag that is not required in BUD02 specs, strange.

I have added the possibility to switch from nip96 to blossom in user settings.
Most blossom server right now seems to be missing the any domain cors settings, The only one that is accessible from anywhere so far is satellite.

Looks pretty good, although it needs a rebase, and I'm getting some errors about getMetaTags not existing. A few other things:

The paperclip button should look like the other buttons
Use this for link-content:

.link-content,
.tiptap [tag] {
  @apply max-w-full overflow-hidden text-ellipsis whitespace-nowrap rounded bg-neutral-200 px-1 no-underline;
}

.link-content.link-content-selected {
  @apply bg-neutral-300;
}

[nit] I have a particular order to imports: external library (svelte, ramda, hurdak), welshman, lib/partials, app. Just try to keep stuff in that order, it makes it easier to look for things. I know this is weird.

[X] Newline rendering issue was solved with your suggestion
[X] Have modified tag so that we can immediately mention people, The behaviour has slightly change,  tag is now display once we hit the space key
[X] I could not reproduce the issue, however it will no longer break if the content is undefined or can't be resolved.
[] I tried with different npub with different editor content, I could not reproduce the bug. Can you send me the content or more step on how to reproduce the bug, does it happen every time?
[X] Background link, mention, tags etc are unchanged, but the text content will now be the "reverse" of the background, so the contrast between text and background is always high.


Coverage worker runs despite build failure

If a coverage worker build fails, if the directory exists (from a previous successful build). it will still run the target.

Fixed by #112


Add scale test in dormant (-short) mode

Signed-off-by: Joshua Packer<EMAIL_ADDRESS>
Include the scale-cluster-curator-controller_test.go for manual scale testing and pod profiling

/cc @leena-jawale

Looks good. Can this be run in unit-tests job?

No. It needs to be run on a full cluster, so its something we could add to end-2-end. You just need to run the make command if your connected to a cluster.  I wanted a profile/scale test that could be run on a real system.

/lgtm


SQLite storage step is very slow

The implementation in RunStore is quite inefficient. In profiling it consumes about 97% of the runtime.

Commit f13f534 improves speed by about 25x in some simple bench checks.
There's probably more low-hanging fruit here: about 2/3rds of remaining execution time is spent in the SQLite codepath, with ~1/3rd spent on the actual simulation codepath. A 2x speedup may still be possible.

The WithTx improvement seems Good Enough ™ for now. Closing.


Failed to locate makeable Electron application

Pre-flight checklist

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project uses.
[x] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
5.2.4
Electron version
30.0.1
Operating system
Win 11 Pro, Version 24H2, Build 26100.2033
Last known working Electron Forge version
5.2.4
Expected behavior
Running npm run make -- --platform win32 on a project (that has been successfully build previously already on OSX and windows) would actually make it build.
Actual behavior
npm run make -- --platform win32
><EMAIL_ADDRESS>make
> electron-forge make --platform win32

√ Checking your system
× Resolving Forge Config

Electron forge was terminated:
Failed to locate makeable Electron application

Steps to reproduce
The forge config is present, of course:
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        23.10.2024     18:21                app
d-----        14.11.2024     16:27                node_modules
d-----        13.11.2024     17:42                out_backup
d-----        18.10.2024     16:07                e2e
d-----        18.10.2024     16:07                src
------        18.10.2024     16:07            953 angular.webpack.js
------        18.10.2024     16:07         517882 README.zip
------        18.10.2024     16:07           5223 CODE_OF_CONDUCT.md
------        18.10.2024     16:07           1053 LICENSE.md
------        23.10.2024     16:28            326 nodemon.json
------        18.10.2024     16:07          55790 CHANGELOG.md
------        18.10.2024     16:07            305 jest.config.js
------        18.10.2024     16:07           1214 HOW_TO.md
------        18.10.2024     16:07            442 tsconfig.serve.json
------        18.10.2024     16:07           9594 README.md
------        18.10.2024     16:07           5393 angular.json
------        14.11.2024     16:28           1459 forge.config.js
------        14.11.2024     16:27        1338945 package-lock.json
------        14.11.2024     16:27           4244 package.json
------        18.10.2024     16:07             29 _config.yml
------        23.10.2024     18:27            916 tsconfig.json
------        18.10.2024     16:07            571 electron-builder.json

Is this package.json from the original OSX codebase enough to tell if the Error is maybe just wrong/misleading and I'm just missing some windows dependencies maybe, or should a minimal repro be prepared?
"dependencies": {
    "@angular/common": "17.3.6",
    "@angular/compiler": "17.3.6",
    "@angular/core": "17.3.6",
    "@angular/forms": "17.3.6",
    "@angular/language-service": "17.3.6",
    "@angular/platform-browser": "17.3.6",
    "@angular/platform-browser-dynamic": "17.3.6",
    "@angular/router": "17.3.6",
    "dymojs": "1.2.0",
    "electron-squirrel-startup": "1.0.1",
    "electron-updater": "6.3.9",
    "remote": "0.2.6",
    "rxjs": "7.8.1",
    "simple-xml-to-json": "1.2.3",
    "tslib": "2.6.2",
    "xml-js": "1.6.11",
    "zone.js": "0.14.4"
  },
  "devDependencies": {
    "@angular-builders/custom-webpack": "17.0.2",
    "@angular-builders/jest": "17.0.3",
    "@angular-devkit/build-angular": "17.3.6",
    "@angular-eslint/builder": "17.3.0",
    "@angular-eslint/eslint-plugin": "17.3.0",
    "@angular-eslint/eslint-plugin-template": "17.3.0",
    "@angular-eslint/schematics": "17.3.0",
    "@angular-eslint/template-parser": "17.3.0",
    "@angular/cli": "17.3.6",
    "@angular/compiler-cli": "17.3.6",
    "@electron-forge/cli": "7.5.0",
    "@electron-forge/maker-deb": "7.5.0",
    "@electron-forge/maker-rpm": "7.5.0",
    "@electron-forge/maker-squirrel": "7.5.0",
    "@electron-forge/maker-zip": "7.5.0",
    "@electron-forge/plugin-auto-unpack-natives": "7.5.0",
    "@electron-forge/plugin-fuses": "7.5.0",
    "@electron-forge/publisher-github": "7.5.0",
    "@electron/fuses": "1.8.0",
    "@ngx-translate/core": "15.0.0",
    "@ngx-translate/http-loader": "8.0.0",
    "@playwright/test": "1.43.1",
    "@types/jest": "29.5.12",
    "@types/node": "20.12.7",
    "@typescript-eslint/eslint-plugin": "7.7.1",
    "@typescript-eslint/parser": "7.7.1",
    "concurrently": "9.0.1",
    "conventional-changelog-cli": "4.1.0",
    "electron": "30.0.1",
    "electron-debug": "3.2.0",
    "electron-prebuilt-compile": "8.2.0",
    "electron-reloader": "1.2.3",
    "eslint": "8.57.0",
    "eslint-plugin-import": "2.29.1",
    "eslint-plugin-jsdoc": "48.2.3",
    "eslint-plugin-prefer-arrow": "1.2.3",
    "jest": "29.7.0",
    "node-polyfill-webpack-plugin": "2.0.1",
    "nodemon": "3.1.7",
    "npm-run-all": "4.1.5",
    "playwright": "1.43.1",
    "ts-node": "10.9.2",
    "typescript": "5.4.5",
    "wait-on": "7.2.0",
    "webdriver-manager": "12.1.9"
  },

Additional information
I was able to run the make command with this package.json and would like to find out if I would have to maintain two different dependencies based on the OS I'm building on, or can I stay on my original package.json from OSX and just add - which ever - necessary things so it works on both OS ?
Working on windows:
"dependencies": {
    "@angular-builders/common": "2.0.0",
    "@angular-devkit/architect": "0.1802.11",
    "@angular-devkit/core": "18.2.11",
    "@angular/common": "17.3.6",
    "@angular/compiler": "17.3.6",
    "@angular/core": "17.3.6",
    "@angular/forms": "17.3.6",
    "@angular/language-service": "17.3.6",
    "@angular/platform-browser": "17.3.6",
    "@angular/platform-browser-dynamic": "17.3.6",
    "@angular/router": "17.3.6",
    "@babel/code-frame": "7.26.2",
    "@babel/helper-environment-visitor": "7.24.7",
    "@babel/helper-module-imports": "7.25.9",
    "@babel/helper-plugin-utils": "7.25.9",
    "@babel/traverse": "7.25.9",
    "@babel/types": "7.26.0",
    "@develar/schema-utils": "2.6.5",
    "@electron/notarize": "2.5.0",
    "@electron/osx-sign": "1.3.1",
    "@istanbuljs/load-nyc-config": "1.1.0",
    "@jridgewell/gen-mapping": "0.3.5",
    "@jridgewell/resolve-uri": "3.1.2",
    "@jridgewell/set-array": "1.2.1",
    "@jridgewell/sourcemap-codec": "1.5.0",
    "@jridgewell/trace-mapping": "0.3.25",
    "@nx/nx-win32-x64-msvc": "18.3.5",
    "@xmldom/xmldom": "0.9.5",
    "ajv": "8.17.1",
    "ajv-keywords": "5.1.0",
    "ansi-regex": "6.1.0",
    "ansi-styles": "6.2.1",
    "app-builder-lib": "25.1.8",
    "camelcase": "8.0.0",
    "caniuse-lite": "1.0.30001680",
    "chalk": "5.3.0",
    "ci-info": "4.1.0",
    "cliui": "8.0.1",
    "compare-version": "0.1.2",
    "data-uri-to-buffer": "6.0.2",
    "debug": "4.3.7",
    "dymojs": "1.2.0",
    "electron-builder": "25.1.8",
    "electron-squirrel-startup": "1.0.1",
    "electron-updater": "6.3.9",
    "emoji-regex": "10.4.0",
    "err-code": "3.0.1",
    "escalade": "3.2.0",
    "fast-deep-equal": "3.1.3",
    "fast-uri": "3.0.3",
    "fetch-blob": "3.1.4",
    "formdata-polyfill": "4.0.10",
    "fraction.js": "5.1.1",
    "fs-extra": "11.2.0",
    "get-caller-file": "2.0.5",
    "get-east-asian-width": "1.3.0",
    "graceful-fs": "4.2.11",
    "is-ci": "3.0.1",
    "isbinaryfile": "5.0.4",
    "json-schema-traverse": "1.0.0",
    "jsonfile": "6.1.0",
    "lazy-val": "1.0.5",
    "listr2": "8.2.5",
    "minimist": "1.2.8",
    "ms": "2.1.3",
    "node-domexception": "2.0.1",
    "node-fetch": "3.3.2",
    "nx": "20.1.0",
    "plist": "3.1.0",
    "promise-retry": "2.0.1",
    "remote": "0.2.6",
    "require-directory": "2.1.1",
    "require-from-string": "2.0.2",
    "retry": "0.13.1",
    "rxjs": "7.8.1",
    "semver": "7.6.3",
    "simple-update-notifier": "2.0.0",
    "simple-xml-to-json": "1.2.3",
    "string-width": "7.2.0",
    "strip-ansi": "7.1.0",
    "tslib": "2.6.2",
    "universalify": "2.0.1",
    "web-streams-polyfill": "4.0.0",
    "wrap-ansi": "9.0.0",
    "xml-js": "1.6.11",
    "y18n": "5.0.8",
    "yargs": "17.7.2",
    "yargs-parser": "21.1.1",
    "zone.js": "0.14.4"
  },
  "devDependencies": {
    "@angular-builders/custom-webpack": "17.0.2",
    "@angular-builders/jest": "17.0.3",
    "@angular-devkit/build-angular": "17.3.6",
    "@angular-eslint/builder": "17.3.0",
    "@angular-eslint/eslint-plugin": "17.3.0",
    "@angular-eslint/eslint-plugin-template": "17.3.0",
    "@angular-eslint/schematics": "17.3.0",
    "@angular-eslint/template-parser": "17.3.0",
    "@angular/cli": "17.3.6",
    "@angular/compiler-cli": "17.3.6",
    "@electron-forge/cli": "7.5.0",
    "@electron-forge/maker-deb": "7.5.0",
    "@electron-forge/maker-rpm": "7.5.0",
    "@electron-forge/maker-squirrel": "7.5.0",
    "@electron-forge/maker-zip": "7.5.0",
    "@electron-forge/plugin-auto-unpack-natives": "7.5.0",
    "@electron-forge/plugin-fuses": "7.5.0",
    "@electron-forge/publisher-github": "7.5.0",
    "@electron/fuses": "1.8.0",
    "@ngx-translate/core": "15.0.0",
    "@ngx-translate/http-loader": "8.0.0",
    "@playwright/test": "1.43.1",
    "@types/jest": "29.5.12",
    "@types/node": "20.12.7",
    "@typescript-eslint/eslint-plugin": "7.7.1",
    "@typescript-eslint/parser": "7.7.1",
    "concurrently": "9.0.1",
    "conventional-changelog-cli": "4.1.0",
    "electron": "30.0.1",
    "electron-debug": "3.2.0",
    "electron-reloader": "1.2.3",
    "eslint": "8.57.0",
    "eslint-plugin-import": "2.29.1",
    "eslint-plugin-jsdoc": "48.2.3",
    "eslint-plugin-prefer-arrow": "1.2.3",
    "jest": "29.7.0",
    "node-polyfill-webpack-plugin": "2.0.1",
    "nodemon": "3.1.7",
    "npm-run-all": "4.1.5",
    "playwright": "1.43.1",
    "ts-node": "10.9.2",
    "typescript": "5.4.5",
    "wait-on": "7.2.0",
    "webdriver-manager": "12.1.9"
  },

Solved: In the codebase, where I got this working on windows, I found the following package: "@nx/nx-win32-x64-msvc": "18.3.5" adding that solved the issue - but why?

Electron Forge in production shouldn't have a dependency on any nx code. Does your repo use NX or Lerna?

I have no clue what is going on, but copy-pasting the exact code to a new folder in order to create the repro, I removed that nx/win dep, and it installed and built just fine. I kind of have the feeling that something about the filesystem is wrong when working in Parallels, as not only tons of reading and writing operations fail with an error, also code changes don't seem to be actually written to disc or something: I run my app, and changes are just not being applied. Welcome to Microsoft land, I guess. Thanks for your help, I will reopen, if this issue appears again and I can reproduce it.


add reference pages to docs

Codecov Report

Merging #62 (f89b0d9) into main (3edff12) will increase coverage by 8.50%.
The diff coverage is n/a.

:exclamation: Current head f89b0d9 differs from pull request most recent head 361e564. Consider uploading reports for the commit 361e564 to get more accurate results

@@            Coverage Diff             @@
##             main      #62      +/-   ##
==========================================
+ Coverage   79.01%   87.52%   +8.50%
==========================================
  Files          19       19
  Lines        1101     1106       +5
==========================================
+ Hits          870      968      +98
+ Misses        231      138      -93

Impacted Files
Coverage Δ

src/dx/utils/date_time.py
73.68% <0.00%> (-21.06%)
:arrow_down:

src/dx/utils/datatypes.py
92.69% <0.00%> (-0.56%)
:arrow_down:

src/dx/settings.py
87.59% <0.00%> (+0.09%)
:arrow_up:

src/dx/formatters/main.py
88.50% <0.00%> (+2.63%)
:arrow_up:

src/dx/utils/formatting.py
83.87% <0.00%> (+3.87%)
:arrow_up:

src/dx/utils/tracking.py
97.53% <0.00%> (+12.26%)
:arrow_up:

src/dx/types.py
96.11% <0.00%> (+28.76%)
:arrow_up:

src/dx/comms.py
60.00% <0.00%> (+30.37%)
:arrow_up:

src/dx/filtering.py
100.00% <0.00%> (+79.36%)
:arrow_up:

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 29240ec...361e564. Read the comment docs.

closing since https://github.com/noteable-io/dx/pull/90 did a lot of this


Habits/Summaries - add chart view

I am starting to track things like daily calories: @calories(xxx) and weight @weight(yyy) in my daily note.
I would love to be able to click to see a pretty graph of this data over time in an HTML popup. thinking that we can maybe use a library to draw simple line charts. https://www.chartjs.org/docs/latest/getting-started/
For now, I see this as most easily invoked via x-callback so you can specify the tag(s) you want in the chart, and the time frame to graph. For simplicity, I think we just pull it from the web like we do in Mermaid.
https://www.chartjs.org/docs/latest/getting-started/
Thoughts?

I've been wanting to have this as well, but have been waylaid with Dashboard rearchitecting first.
I think we should have a call to talk through architecture options. There's the generate-and-embed-in-note approach, or the HTMLWindow approach. Perhaps others too ...

BTW, it would be especially cool to track calories and weight on the same chart with two axes.

Some use cases for me:
Basic Line chart of data - e.g. @weight(xxx) over the period A to B
Line chart with multiple lines - e.g. @carbs() @fats() @protein() showing trends over various days
Dual-axis line chart - e.g. @weight() on one axis and @calories() on the other - days being the x axis
In terms of output,

I am thinking for starters, it's just a transient pop-up that renders the data in an HTML window based on an xcallback
We could render and place in the note, but I wouldn't use that because i don't want heavy images lying around in all my daily notes. I can see the value though in having a chart that could stick around for posterity (e.g. here was my monthly progress from May)

If you haven't already, try out the weeklyStatsToCSV command having updated settings for @weight, @carbs, @calories etc.  (See README for where it writes to.)
I spent many hours yesterday improving and fixing date logic in it (which lives in jgclark.Summaries::forCharting.js) hoping that it will be useful.

OK, I think requirements are similar.
Location: charts produced in either temporary window or saved-into-note form.
Data sets for charts:

single line chart covering multiple data sets, with all data sets auto-scaled (so scale not shown). Actual data points available on hover, or optionally always shown.
multiple line charts each with a single (shown) scale for 1+ data sets. Actual data points available on hover.

Data duration: user-settable number of weeks (default 23) of months (default 12) shown
Generation triggered by /command or x-callback.

So, next challenge is to agree a way to define chart(s).  Options that occur to me are:

In JSON, so it can be passed to x-callback?
In YAML files that live as NP notes. (Assumes YAML handling and display improves in time in NP editor.) These notes are referenced in x-callback calls.
In JSON code blocks that live in an NP note. These blocks are referenced in x-callback calls.

@jgclark maybe now it's time to talk this through. One (maybe crazy) idea is (for a first step), to put the full chart.JS code in a codeblock in a note whose title is included in the xcallback. The codeblock references a data object that is populated by the plugin at runtime. This is definitely not naïve user-friendly, but might be a good way to prototype various charts and play around with it to see what applications are worth hard coding into the plug-in. Happy to discuss live if u want to suggest some times


How to share Pinecone vectors with different computers?

I successfully run on one computer at work. Then go home and found that I have to create a workspace again and upload documents to Pinecone again. I expect since index is on Pinecone therefore the workspace can be shared too. I found this repo today, I am new, Just a little hint would be very much appreciated.

Currently syncing vectors to a vector db that wasn't created on the instance is not supported.
however!
You can export the DB from the instance on the instance which created the vectors and import it into your new instance. That will keep everything up to date cross-instance.

Hi there,
I gratfully have reviewed the answer, but I still require more hints on how to carry out the export/import process within this Docker container. Would someone be able to provide me with further clarification or point me in the direction of any relevant documentation?
Thank you for your help!

Clicking the Key Icon in the top right of sidebar should display a modal with a tab for Import/Export Database which is what you would need to do.
Once the DB is exported you can then upload that .zip file into the new instance that has no information and the data will be synced. The Pinecone data is stored on the Pinecone.io cloud so there is nothing to migrate - you just need to have your instance know about it


Week 1 Tri 3 - Luke Riggins

Test Corrections
2.2
2.3

I am giving Riggi a 2.1 because he completed all the college board assignments and the corrections for them. He took notes and completed problems for the 2.2 and 2.3 notes but he did not finish the hacks which is why he got this score.


add google drive link to template on how to add table to internal sgid

this doc is a reminder on what not to forget when adding new data to the sgid.

Looks good


Face extraction for animals

the results are very convincing and i was wondering if this can be applied for animals like pets or cats?
Thanks.

As far, No


template generation with asset path prefix

Prefix all script and stylesheet paths with asset path prefix based on webpack output.publicPath config.

Thanks a lot! ✨


DDOS-260

DDOS-260
https://itomych.atlassian.net/browse/DDOS-260

changed NetworkDebugLog;
changed NetworkClient;
changed ViewController

Look like "// TODO:" was used instead "// MARK:" in 8 places. Please change TODO to MARK or clarify what should be done in the scope of TODO.


Notifications to the users about changes of their parking slot

DB should handle parking color expire date and time.
Time estimation :12-14 hours

Not relevant to this version of the project, has been closed.


ARTEMIS-4115 ArrayIndexOutOfBoundsException when dup cache size is 0

@jbertram test failures...
if you could also run a whole CI in your env before we merge this please?

Testsuite was clean. Merging...


Sheet names containing a ' cause parse errors on build

We used the name
Heckin' Good Doggos
While it correctly escapes it in some places, it doesn't seem to escape it inside the pug file.
 Processing Heckin_Good_Doggos.pug
=========================
==== PUG PARSE ERROR ====
=========================
/home/techyshishy/Code/hgd-sheet/source/Heckin_Good_Doggos.pug:16:31
    14| +hidden({name:'template start',value:`@{whisper}&{template:${templateName}} {{character_name=@{character_name}}} {{character_id=@{character_id}}}`})
    15| include rolltemplate/_index.pug
  > 16| +kscript('Heckin'_Good_Doggos')
--------------------------------------^
    17|   //- All additional javascript files should be included in the index file
    18|   include ./javascript/_index.pug

Mismatched Bracket: )

Thanks @TechyShishy. I'll get a fix put in for that over the weekend.


chore add back pipelinex in master

Proposed changes
Issue Number: close #xxx

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