Utility classes (off the standard ember path) aren't being instrumented

I am literally in the middle of making a repro for this and went to make a new issue; I have a helper object in app/utils/..., and it doesn't get shown as covered. Ember-cli does suggest that 'utils' is the right place under http://www.ember-cli.com/#using-modules, but it doesn't seem to help. Moving it under 'helpers' doesn't make any difference, either.
Weirdly, even if I put my helper class under /controllers, it still doesn't register as being covered. It's just some bare utility functions, roughly like:
(app/utils/my-utils.js)
export default {
helper1: function() { return "foo"; }
}
and I have a test that does
import myUtils from 'app/utils/my-utils';
module("myUtils tests");
test('helper works', function() {
equal(myUtils.helper1(), "foo");
});
but that doesn't get shown as covered; I'm wondering if the issue is that it's not part of the Ember object hierarchy, rather than it being in an unexpected path.
(I also have some global code in my real helper file that's outside the 'export default', and that doesn't show as covered either, for what it's worth)

None of my app/utils are reported as covered too, are there any workarounds or fixes?

@topaxi Not currently.  The project instruments (wraps classes with JavaScript that monitors the lines executed)  any class included in the requirejs.entries loaded by ember-cli.  Unfortunately, this doesn't include anything that isn't in the standard trees ember-cli monitors.
The only solution I've thought of currently is to walk the full app tree and include any files not already in the requirejs.entries; however, I haven't had time to test this idea.  It's definitely on my todo list, but it will probably be a few weeks before it reaches the top of my priorities.

I have the same issue here, but looks like it is just initializers and utils, included in the ember cli tree, which are shown in coverage, but reported as not covered. Tho they are all in require.entries (I removed irrelevant entries there to make it smaller):
JSON.stringify(
  Ember.keys(require.entries).filter(function (entry) {
    return /\/(utils|initializers)\//.test(entry);
  })
)

"[
  "wonder-app/initializers/contact-book-service",
  "wonder-app/initializers/cordova-service",
  "wonder-app/initializers/inject-notifier",
  "wonder-app/initializers/qna-service",
  "wonder-app/initializers/session-service",
  "wonder-app/utils/browser/uuid",
  "wonder-app/utils/computed/fmt",
  "wonder-app/utils/dial-prefix-for-country",
  "wonder-app/utils/is-coercible-number",
  "wonder-app/utils/parse-phone",
  "wonder-app/utils/qna/actions",
  "wonder-app/utils/qna/hooks",
  "wonder-app/utils/string-to-map",
  "wonder-app/utils/view/is-dom-accessible"
]"

Then they all appear in the coverage report, but appears as not covered, tho they're all or almost called, even have some tests for most of them so for sure they're called ;-)

That's interesting, I guess I just assumed they weren't in the requirejs entries.  I haven't had a report of them showing up in coverage before, maybe CLI changed.  Not sure why they would be uncovered if they got instrumented, but it definitely gets us closer.

Ah, to clarify, I'm seeing the same thing; when I said "[my helper object] doesn't get shown as covered", I meant "shows up in the report but with all lines not showing as covered". But as I said, I don't think it's related to paths, I think it's related to how they get loaded, because non-"Controller" objects in /controllers don't get shown as being covered even when they are.

Yup, I guess EmberCLI loader does the container.register(...) before this addon's instrument them. So it's just a matter of where to make the call which is instrumenting the require.entries items.

might be worth looking app-boot.js (https://github.com/ember-cli/ember-cli/blob/master/lib/broccoli/app-boot.js).
The addon could return contentFor(‘app-boot’) to hop in early in the process.
It’s on my list to experiment with this hook - but it definitely is before the app boots.

On Mar 11, 2015, at 9:48 PM, Huafu Gandon<EMAIL_ADDRESS>wrote:
Yup, I guess EmberCLI loader does the container.register(...) before this addon's instrument them. So it's just a matter of where to make the call which is instrumenting the require.entries items.
—
Reply to this email directly or view it on GitHub https://github.com/sglanzer/ember-cli-blanket/issues/18#issuecomment-78414677.

I was opening a new issue to report the same but I'll add my comments here.
The issue is not that the other assets are not in the requirejs entries but rather that in the process of adding coverage to a file blanket ends up requiring the other dependencies before they themselves have been covered.
I've confirmed this by setting breakpoints in the 'imported' file and indeed it is in uncovered code
to @huafu's comment - I believe we're hooking in early enough - the reason I ended up down this rat hole was chasing something imported into an initializer
I'm thinking about options here - if blanket greedily consumes imports then we need to be able to override require
Other options (radical) include annotating the code as a postProcess step in the addon
open to discussion

I've put up a branch testing out the concept of monkey-patching require
Before Coverage:

After Coverage:

The uncovered code in stock ember-cli-blanket is utils/util.js - it is imported from a 'covered' file.
pro-forma branch is up at: https://github.com/jschilli/ember-cli-blanket/tree/stub-require
all of the changes are isolated in: https://github.com/jschilli/ember-cli-blanket/blob/stub-require/lib/blanket-loader.js
@huafu - I was able to verify that with the require approach we can hook in early enough to capture initializers so we have that going for us
I'd like to get feedback on the approach of hijacking require.
Another alternative I'm thinking about is continuing with the original approach of navigating through requirejs.entries but pre-processing dependencies before letting blanket do its thing.  I think it will work but it's more code and we then have to deal with cycles etc
thoughts?

I have app/mixins not covered also

@Coobaha
npm i "git://github.com/jschilli/ember-cli-blanket.git#stub-require" and give it a whirl - I haven't tried mixins specifically but believe it should be covered

@jschilli
your branch shows 100% coverage for file, but I have no tests for it :)

@Coobaha not enough info to help - imported file? public repo? blanket will cover the lines if they are executed - regardless of who calls them

Sorry, you are right @jschilli . After isolating coverage worked as it should - all ok :+1:

I believe the latest commit from @jschilli addresses this issue.  Any modules imported into a module on the standard path will be included in the coverage.
This should address modules such as mixins, utility function modules or object models.
Version 0.3.3 has been released with these changes, I'll leave this issue open for a few days to gather feedback, but the early tests I've run with Jeff's change set look good.

Note that modules that aren't imported won't be covered still, but I believe this should be addressed with an appropriately scoped issue and will likely require a rewrite using the postProcess hook.  It's also much less of priority in my opinion.

@sglanzer are there specific examples that aren't covered? that would be meaningful?  initializers?
My question is if a module is not imported is it ever executed? unless that's the point - you want to report 0% coverage on modules in requirejs.entries that are never executed.  I have some ideas on that

I'll self reply here - I added blanket back to my main app and now very clearly see the issue with not covering requirejs.entries.
we're only covering files that are required - it's pretty important to reflect those files that aren't covered at all.
I'll take a swing @ this - may be a few days

You rule Jeff =)


Feature Request: Change label colors

I have labels setup in Gmail, and for example, one of these labels is the color yellow; but in NylasN1--it's showing up as purple.

+1. According to https://github.com/nylas/N1/issues/510#issuecomment-160738544 and the gmail API this is not possible.
@jstejada Can this task be renamed to Feature Request: Change label colors because the current purple color for every label is extremely frustrating. Secondly, can this be added to the roadmap for voting? Once this is added https://trello.com/c/UI16Nkc7/13-manage-labels-on-a-per-account-basis it sounds feasible to add a color picker to the gui.

Hi @patrickheeney - yep I'll add this to Trello. Thanks!

Feel free to upvote here: https://trello.com/c/idme4T13/56-change-label-colors

I personally love how airmail handles label colors. You don't pick the color yourself, but the software does a nice gradient for all your labels :+1:

+1 for Gradient. Right now all my label colors are that same tacky purple color (horrible UX with dozens of labels). The gradient idea would be perfect to quickly solve this issue. Later they could re-factor to make these customizable and still default to the gradient.

+11 for Gradient

My comments on #2339 are as follows:
Ok, I understand the Google label color limitation, which is fine. I don't use label colors myself. Most of these tickets are closed around label color, but one #808 has the fine distinction of proposing a gradient (like airmail). That would be a big improvement over random. Colors mean something, so random colors are discombobulating. If I could choose a grey (like the sidebar without colors) that would be fine. A better option would be a gradient because that would inform me better about where in the list of labels I am (and I use priority + alpha sort, so it would match my mental model).
Better: grey labels as an option or default
Best: gradient labels as an option or default
Superbest: choice of random color, grey, or gradient label
Superbest++: same on the sidebar (issue #1803 )

I use red and green Gmail labels for emails from CI, so automatically assigned gradient colors are pretty much the worst option for me.

Note that AirMail's gradient just picks the default label color. It definitely allows you to manually assign colors.


Refactor solver

I am investigating why that one test case fails. Currently I am unable to reproduce it locally.

These changes came up because I wanted to refresh myself on how the solver works. I realized that our ChoiceStack does not really add much value, and gave more power to the ChoiceManager. It is now more  involved in backtracking.

Slight decrease in coverage (again), otherwise should be fine.

Ready to merge after conflicts with master are resolved.

I went ahead and merged this after your explicit confirmation :)


CodeGeneration.targets flags github PR links as GithubUrlsWithoutHash

example
D:\a\1\s\eng\CodeGeneration.targets(38,5): error : Following GitHub URLs do not contain commit hash: https://github.com/Azure/azure-rest-api-specs/pull/10262 please use permalinks for code generation inputs (see https://help.github.com/en/github/managing-files-in-a-repository/getting-permanent-links-to-files)  [D:\a\1\s\sdk\keyvault\Azure.Security.KeyVault.Administration\src\Azure.Security.KeyVault.Administration.csproj]

I think this is correct. We want a link pointing to a specific version of the file even if it's part of the RP.


[SPARK-25690][SQL] Analyzer rule HandleNullInputsForUDF does not stabilize and can be applied infinitely

What changes were proposed in this pull request?
The HandleNullInputsForUDF rule can generate new If node infinitely, thus causing problems like match of SQL cache missed.
This was fixed in SPARK-24891 and was then broken by SPARK-25044.
The unit test in AnalysisSuite added in SPARK-24891 should have failed but didn't because it wasn't properly updated after the ScalaUDF constructor signature change. So this PR also updates the test accordingly based on the new ScalaUDF constructor.
How was this patch tested?
Updated the original UT. This should be justified as the original UT became invalid after SPARK-25044.

Test build #97273 has started for PR 22701 at commit 736625b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3894/
Test PASSed.

Test build #97273 has finished for PR 22701 at commit 736625b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97273/
Test PASSed.

Test build #97283 has started for PR 22701 at commit dfa301e.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3902/
Test FAILed.

Test build #97283 has finished for PR 22701 at commit dfa301e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97283/
Test PASSed.

LGTM
Thanks! Merged to master/2.4


Gateway keys can have subpath-level permissions

Addresses CVM-1427.
Allow restricting the validity of gateway keys to repository subpaths.

Can be merged when Travis is green and the CVMFS integration tests are ok.


DB_URL in Prisma Client's Environment Setup Guide should be changed to MySQL.

Problem
I would like to participate in the development of Prisma.
When I was building the Prisma client environment, I found a difference between the database specified in src/packages/client/fixtures/blog/prisma/schema.prisma and the database specified in the environment building guide.
In schema.prisma, mysql is specified, but in the guide, it is specified as YOUR_POSTGRES_DB_URL.

Suggested solution
I want to change the guide as follows
- 4. export DB_URL=YOUR_POSTGRES_DB_URL
+ 4. export DB_URL=YOUR_MYSQL_DB_URL

Alternatives
The environment builder can look up the specified DB by looking at schema.prisma by himself.

Additional context
This is my first OSS activity. And I am not a high level developer. Therefore, I may be wrong, so please consider it carefully.

Thanks @show-coco!
So this is part of the fixtures folder, it's like a sandbox where we change things / develop locally.
So it was probably postgres but someone changed it to mysql I guess to try something there.
Feel free to change it to run things.
I edited the guide to make it more generic
https://github.com/prisma/prisma/commit/dc716810edad0456010ae901b94d7bd5b7a9fbbd


Add contributor action

From GitHub:
https://www.youtube.com/watch?v=VFRHkPX5f3k
https://github.com/marketplace/actions/contributors-action
I slapped it into bluefin but from chatting with p5 we're thinking this might be bettor off in it's own workflow yaml file so it's not blocking builds, etc. And it'd be easier to add a single file to each repo than trying to inline another action in the existing files. Thoughts?

The website does a better job than this, skipping.


fix (curriculum): include word nesting & comments nutrition-label-step-43

Add comments to code to clear up confusion about where user's should actually be writing their code, as this has been the cause of problems and frustration for some. Also improve the description to incorporate the use of the phrasing 'nesting' in a clear and understandable manner as per suggestions in issue #49017
Checklist:

[ X ] I have read freeCodeCamp's contribution guidelines.
[ X ] My pull request has a descriptive title (not a vague title like Update index.md)
[ X ] My pull request targets the main branch of freeCodeCamp.
[  X ] I have tested these changes either locally on my machine, or GitPod.

fix #49017

Improve the description to incorporate the use of the phrasing 'nesting' in a clear and understandable manner as per suggestions in issue #49017. Also, added comments to code to clear up confusion about where user's should actually be writing their code, as this has been the cause of problems and frustration for some.

To solve this issue:
* change the wording to what agreed upon in the issue.

* change step 53 as well.

Can you edit the PR title to reflect on our conviction, this isn't how you add scope

Yes, of course and thanks for the comment. I've made the changes, I hope all is ok now. Let me know if there's anything else I can change or improve 🙂. I'll take a look at step now 53 too.

To solve this issue:
* change the wording to what agreed upon in the issue.

* change step 53 as well.

Can you edit the PR title to reflect on our conviction, this isn't how you add scope

@Sboonny Done, added a similar description to step 53 👍🏻


There is no  Service Setup

Service Setup does not exist, I assume this is service management setup?

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

ID: 85fe715c-5a06-4d19-01a0-b41b978a58e9
Version Independent ID: 51067fe1-aba0-af2d-c501-ffde32fe115d
Content: Set Up Service Management Processes - Business Central
Content Source: business-central/service-setup-service-processes.md
Service: dynamics365-business-central
GitHub Login: @bholtorf
Microsoft Alias: bholtorf

Thank you for the feedback. The topic has been updated and will be available within one week.


"No session currently bound to execution context" error when configuring multiple data sources

I"m upgrading one of our internal apps to 0.8.1which connects to several data bases.  After the upgrade, we started getting "No session currently bound to execution context" when we attempt to connect to additional databases.  The first one will work, all others fail.
I'm still wrapping my head around DW's internals, but i think the issue may lie with the UnitOfWorkApplicationListener.  Per the code notes, UnitOfWorkApplicationListener is registered as a singleton with Jersey.  I think DW is creating a UnitOfWorkApplicationListener per DataSourceFactory and thus attempting to add a second singleton of UnitOfWorkApplicationListener into Jersey.  Here is a gist showing this behavior.
https://gist.github.com/cbehrends/08caebdb747e1f7e8a31
and another showing the same test passing in 0.7.1
https://gist.github.com/cbehrends/e3717140a52b4f7d78ff
I've noticed that when my app loads I get the the following warning.
WARN  [2015-05-25 15:50:20,443] org.glassfish.jersey.internal.Errors: The following warnings have been detected: WARNING: Cannot create new registration for component type class io.dropwizard.hibernate.UnitOfWorkApplicationListener: Existing previous registration found for the type.
If you think I'm on the right track here, I'd be more than happy to submit a patch.  Any guidance would be appreciated.

I've actually refactored my services so that I no longer require multiple datasources.  If you think this is something worth fixing I'd still be willing to pitch in and take a look shot at it.

I've just encountered this issue as well, I've dropped down to 0.7.1 for now. Any chance on a fix for this in a future version?

Support for several data sources/Hibenate bundles was contributed in #1276.


vscode-extensions: upgrade in batch

Description of changes
I went through the list of vscode extensions and updated most of those that were just a simple buildVscodeMarketplaceExtension call without any patches or other weird fields.
During this process, I discovered the following things, but didn't act on them to keep this PR simple. They should probably be fixed in one or multiple separate PRs.

coenraads.bracket-pair-colorizer no longer exists and should be removed
coenraads.bracket-pair-colorizer2 is deprecated and could be removed
faustinoaq.lex-flex-yacc-bison no longer exists and should be removed
msjsdiag.debugger-for-chrome is deprecated and could be removed
silvenon.mdx is deprecated and could be removed or replaced by the official extension
jpoissonnier.vscode-styled-components no longer exists (moved to styled-components.vscode-styled-components?) and should be removed or replaced
The file should be reformatted by nixpkgs-fmt
matklad.rust-analyzer should be moved to the aliases section
The github.* packages are all defined inside one {} table expression, unlike other cases where one author has multiple extensions

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 223308 run on x86_64-linux 1

114 packages built:

vscode-extensions.a5huynh.vscode-ron
vscode-extensions.alefragnani.bookmarks
vscode-extensions.alefragnani.project-manager
vscode-extensions.angular.ng-template
vscode-extensions.antfu.icons-carbon
vscode-extensions.antfu.slidev
vscode-extensions.astro-build.astro-vscode
vscode-extensions.asvetliakov.vscode-neovim
vscode-extensions.baccata.scaladex-search
vscode-extensions.benfradet.vscode-unison
vscode-extensions.bierner.emojisense
vscode-extensions.bierner.markdown-checkbox
vscode-extensions.bierner.markdown-emoji
vscode-extensions.bierner.markdown-mermaid
vscode-extensions.bmalehorn.vscode-fish
vscode-extensions.bmewburn.vscode-intelephense-client
vscode-extensions.bodil.file-browser
vscode-extensions.bradlc.vscode-tailwindcss
vscode-extensions.catppuccin.catppuccin-vsc
vscode-extensions.chris-hayes.chatgpt-reborn
vscode-extensions.christian-kohler.path-intellisense
vscode-extensions.codezombiech.gitignore
vscode-extensions.cweijan.vscode-database-client2
vscode-extensions.daohong-emilio.yash
vscode-extensions.dart-code.dart-code
vscode-extensions.dart-code.flutter
vscode-extensions.denoland.vscode-deno
vscode-extensions.disneystreaming.smithy
vscode-extensions.divyanshuagrawal.competitive-programming-helper
vscode-extensions.donjayamanne.githistory
vscode-extensions.edonet.vscode-command-runner
vscode-extensions.eg2.vscode-npm-script
vscode-extensions.elmtooling.elm-ls-vscode
vscode-extensions.emmanuelbeziat.vscode-great-icons
vscode-extensions.ethansk.restore-terminals
vscode-extensions.foam.foam-vscode
vscode-extensions.formulahendry.code-runner
vscode-extensions.genieai.chatgpt-vscode
vscode-extensions.github.codespaces
vscode-extensions.github.copilot
vscode-extensions.github.github-vscode-theme
vscode-extensions.github.vscode-pull-request-github
vscode-extensions.gitlab.gitlab-workflow
vscode-extensions.golang.go
vscode-extensions.grapecity.gc-excelviewer
vscode-extensions.graphql.vscode-graphql
vscode-extensions.haskell.haskell
vscode-extensions.humao.rest-client
vscode-extensions.iciclesoft.workspacesort
vscode-extensions.influxdata.flux
vscode-extensions.ionide.ionide-fsharp
vscode-extensions.james-yu.latex-workshop
vscode-extensions.jellyedwards.gitsweep
vscode-extensions.jkillian.custom-local-formatters
vscode-extensions.jock.svg
vscode-extensions.kahole.magit
vscode-extensions.kubukoz.nickel-syntax
vscode-extensions.lokalise.i18n-ally
vscode-extensions.mads-hartmann.bash-ide-vscode
vscode-extensions.marp-team.marp-vscode
vscode-extensions.matangover.mypy
vscode-extensions.maximedenes.vscoq
vscode-extensions.mechatroner.rainbow-csv
vscode-extensions.ms-azuretools.vscode-docker
vscode-extensions.ms-kubernetes-tools.vscode-kubernetes-tools
vscode-extensions.ms-pyright.pyright
vscode-extensions.ms-toolsai.jupyter-keymap
vscode-extensions.ms-toolsai.jupyter-renderers
vscode-extensions.ms-toolsai.vscode-jupyter-cell-tags
vscode-extensions.ms-vscode.PowerShell
vscode-extensions.ms-vscode.anycode
vscode-extensions.ms-vscode.cmake-tools
vscode-extensions.ms-vscode.hexeditor
vscode-extensions.mskelton.one-dark-theme
vscode-extensions.mvllow.rose-pine
vscode-extensions.ocamllabs.ocaml-platform
vscode-extensions.octref.vetur
vscode-extensions.oderwat.indent-rainbow
vscode-extensions.phoenixframework.phoenix
vscode-extensions.pkief.material-icon-theme
vscode-extensions.pkief.material-product-icons
vscode-extensions.prisma.prisma
vscode-extensions.redhat.java
vscode-extensions.redhat.vscode-xml
vscode-extensions.redhat.vscode-yaml
vscode-extensions.rioj7.commandOnAllFiles
vscode-extensions.ritwickdey.liveserver
vscode-extensions.roman.ayu-next
vscode-extensions.scala-lang.scala
vscode-extensions.scalameta.metals
vscode-extensions.shardulm94.trailing-spaces
vscode-extensions.sonarsource.sonarlint-vscode
vscode-extensions.stephlin.vscode-tmux-keybinding
vscode-extensions.stkb.rewrap
vscode-extensions.svelte.svelte-vscode
vscode-extensions.svsool.markdown-memo
vscode-extensions.tabnine.tabnine-vscode
vscode-extensions.tamasfe.even-better-toml
vscode-extensions.thenuprojectcontributors.vscode-nushell-lang
vscode-extensions.tiehuis.zig
vscode-extensions.tobiasalthoff.atom-material-theme
vscode-extensions.tuttieee.emacs-mcx
vscode-extensions.usernamehw.errorlens
vscode-extensions.vincaslt.highlight-matching-tag
vscode-extensions.vscjava.vscode-java-debug
vscode-extensions.vscjava.vscode-java-dependency
vscode-extensions.vscjava.vscode-java-test
vscode-extensions.vscjava.vscode-maven
vscode-extensions.vscjava.vscode-spring-initializr
vscode-extensions.vscodevim.vim
vscode-extensions.vspacecode.vspacecode
vscode-extensions.vspacecode.whichkey
vscode-extensions.yzhang.markdown-all-in-one
vscode-extensions.zhuangtongfa.material-theme

@Garmelon Feel free to open a new PR handling all cases you listed, but nixpkgs-fmt.


merge: test -> main

PR
BY: @s0me1newithhand7s
New:
Ground for multi-host config;
Get rid of nix-darwin;
Why:
Finilase last changes;
Ping hand7s:
@s0me1newithhand7s

LGTM; merge


Multiple consumers

Allow for multiple consumer streams, fixed typing issue

relates to https://github.com/frmscoe/rule-076/issues/19


ex2: design APIs for the GET requests

Design APIs for the GET requests.

API for all the list of cat pictures, with pagination and filters
API for one particular cat picture

/api/cats: the list of all cats

offset: pagination
limit: pagination
name: filter


#Setting the namespace via the package attribute in the source AndroidManifest.xml is no longer supported. in andorid

Hi @tushar-kuchch. I've recently ran into this problem as well. I upgraded my project to android gradle version 8.1.1 and I'm now getting the error message. I hope that we are talking about the same issue as you didn't provide a description:
Incorrect package="com.ibits.react_native_in_app_review" found in source AndroidManifest.xml: /Users/christiaanvanderberg/ODO/rn-app/node_modules/react-native-in-app-review/android/src/main/AndroidManifest.xml.
Setting the namespace via the package attribute in the source AndroidManifest.xml is no longer supported.
Recommendation: remove package="com.ibits.react_native_in_app_review" from the source AndroidManifest.xml: /Users/christiaanvanderberg/ODO/rn-app/node_modules/react-native-in-app-review/android/src/main/AndroidManifest.xml.
As stated above the solution is to remove "package="com.ibits.react_native_in_app_review" from androidManifest and add it to the build.gradle file like:
android {
namespace "com.ibits.react_native_in_app_review"
...
}
I do hope that the repo makes the necessary changes. This isn't the only repository that has given me this error.


Type hinting does not help to detect invalid match cases

Godot version
4.0 dev (5352cf8e2f)
System information
Linux Mint 20
Issue description
GdScript 2.0 match statement does not take full advantage of type hints. Consider following code:
	var some_int: int = 1
	match(some_int):
		1.0:
			print("matched with float")
		1:
			print("matched with int")

As you can see variable some_int will be always of type int. Match statement below does not really take advantage of this information and allows creation of branch that matches index against float pattern. This pattern will never be matched obviously as match statement is strongly typed. Code like that is likely to be the result of programmer error, syntax checker should help us to detect this either by preventing this code from compiling or at least issuing warning.
Steps to reproduce
put this code in gd script editor
	var some_int: int = 1
	match(some_int):
		1.0:
			print("matched with float")
		1:
			print("matched with int")

Minimal reproduction project
No response

Related to https://github.com/godotengine/godot/issues/60145.


once a limit is set xbox and other devices cant log in

I have setup  a limit for my Xbox but this has stopped me from logging into Xbox live can anyone help

Free all

Freeing the device and restarting your XBOX should do the job. If that's not the case, the issue has nothing to do with EvilLimiter.


[Bug]: TypeError: ESConnection.search() got an unexpected keyword argument 'idxnm'

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Branch name
main
Commit ID
33e5e5db
Other environment information
Hardware parameters: Tesla T4
OS type: Ubuntu 20.04 (Host machine)

Actual behavior
Chunk Method: Knowledge Graph
Error: TypeError: ESConnection.search() got an unexpected keyword argument 'idxnm'
When chatting with a Knowledge base, it raised this error.
Expected behavior
No error when chatting
Steps to reproduce
1. Following official guide to start RAGFlow with docker.
2. Start a chat with a Knowledge base which chunked by Knowledge Graph.
3. run
docker logs -f ragflow-server
showing the following logs.

Additional information
Traceback (most recent call last):
File "/ragflow/api/apps/conversation_app.py", line 181, in stream
for ans in chat(dia, msg, True, **req):
File "/ragflow/api/db/services/dialog_service.py", line 210, in chat
kbinfos = retr.retrieval(" ".join(questions), embd_mdl, tenant_ids, dialog.kb_ids, 1, dialog.top_n,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/rag/nlp/search.py", line 380, in retrieval
sres = self.search(req, [index_name(tid) for tid in tenant_ids], embd_mdl, highlight)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/graphrag/search.py", line 71, in search
ent_res = self.es.search(deepcopy(s), idxnm=idxnm, timeout="600s", src=src)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ESConnection.search() got an unexpected keyword argument 'idxnm'

Hello. I want to enquiry when the bug can be fixed? Because it is really important.
In the current version, all functions which involve the knowledge graph-based construction method do not work, including the offical demo webset (https://ragflow.io/), api and chat interfance.
If possible, I hope that you can fix the bug as soon as possible. It is very IMPORTANT for me!
Thank you for your time and understanding!

Pull the dev version of docker.


fix: return none for deprecated/not available attrs

@travisghansen what do you think about this? We can then keep the entity attributes on the integration (they will just be None for the ones that don't exist)

I like it and don’t think it introduces any kind of bad behavior for folks trying to do advanced stuff.


[Bug] Evaluate usage of DateTime.TryParse for performance

Which version of Microsoft.IdentityModel are you using?
latest version.
Where is the issue?

[x] M.IM.JsonWebTokens
[ ] M.IM.KeyVaultExtensions
[ ] M.IM.Logging
[ ] M.IM.ManagedKeyVaultSecurityKey
[ ] M.IM.Protocols
[ ] M.IM.Protocols.OpenIdConnect
[ ] M.IM.Protocols.SignedHttpRequest
[ ] M.IM.Protocols.WsFederation
[ ] M.IM.TestExtensions
[x] M.IM.Tokens
[ ] M.IM.Tokens.Saml
[ ] M.IM.Validators
[ ] M.IM.Xml
[ ] S.IM.Tokens.Jwt
Other (please describe)

Repro
Looking at a CPU profile of validating JWT tokens, between 5-8% of the time is spent in 2 calls to DateTime.TryParse:
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/753959a8af318497ecf60c466a23f7c972f310a0/src/Microsoft.IdentityModel.Tokens/Json/JsonSerializerPrimitives.cs#L713
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/753959a8af318497ecf60c466a23f7c972f310a0/src/Microsoft.IdentityModel.JsonWebTokens/JwtTokenUtilities.cs#L602-L604
For every string claim in the JWT, we are calling DateTime.TryParse on each value, whether it is expected to be a DateTime or not. This is expensive. We should consider if can eliminate these calls, or only call them if necessary.

Excellent find, this was added for backcompat.
We should state what claims we will consider as a possible datetime, ignore the rest.
I think we need to wrap this in a AppContext switch as we could break users.
We are investigating an API that will give users the ability to step in front of property claim.
When that API is ready, users will be able to handle specific claims.


Make block diagram for software components

ARM - bluetooth communications, signal conditioning control, data acquisition, battery monitoring
Android - bluetooth comms, settings, display

Too late for report, but might be nice for block diagram,

Done, but could be made better


feat: astro-font - optimize fonts & prevent CLS

Astro Font: https://www.launchfa.st/blog/building-astro-font
Changes
This PR integrates astro-font which automatically generates the fallback font and pass it as the CSS Variable.

Hello!
Thanks for this, I was just thinking about needing to tackle this!
Though - this solution seems to markedly increase the amount of CLS compared to the previous setup.
You'll note that the fallback font is dramatically larger than the final font.
Before
https://github.com/zolrath/furd-dev/assets/454563/fd888ab0-aa0b-4d02-8889-bff11bfbe855
After
https://github.com/zolrath/furd-dev/assets/454563/8f1ee89b-80a1-40ca-a6dd-e1d456b93195


Update README.md

@kristerkari Just a few docs updates. Do you also want your name in the copyright? I just noticed it's not there, but you've done like half the work! 😀

Do you also want your name in the copyright? I just noticed it's not there, but you've done like half the work!

I does not really matter that much to me if it's there or not :)


upgrade rubocop to 1.41.1

Signed-off-by: Andrew Fader<EMAIL_ADDRESS>

It mainly looks great, thank you. I had a few specific questions (see above).
Sorry that this "simple" task was less simple than intended :-).

No problem, it's not too bad, fairly standard stuff overall though it can get fiddly

I've approved. Go ahead and merge it. This is one of the first "significant code changes" we're merging in from you. Thank you & I look forward to more :-).

thank you!


Wiki: document tests and snekbox

Snekbox

[ ] Mention that snekbox is an optional requirement.
[ ] Link to documentation for setting up snekbox (the README.md on GitHub is fine).
[ ] Document configuring urls.snekbox_eval_api in the config.

Tests

[ ] Show how to run tests and some basics on interpreting coverage results.

This could be a separate article so it can be shared with the site.

[ ] Link to the README.md in the tests directory on GitHub.

Yes, this does describes how run tests but is too specific to the bot so a generic article on how to run tests is a good idea.
Consider taking out the more generic parts and making it a new article on the wiki which all projects could use. The bot-specific docs could go in yet another new article.

Maybe snekbox should be included in docker-compose 🤔

#988 added snekbox to the docker-compose, so no configuration needs to be done for it anymore.

Pretty much everything here seems to be completed now. We don't describe how to set snekbox up on host, but that's by design since docker is easier.
Tests are mentioned here: https://www.pythondiscord.com/pages/guides/pydis-guides/contributing/bot/#running-tests, we don't have a general guide on site, although there's an issue for documenting testing on site here https://github.com/python-discord/site/issues/678


Correcting numbering of scintillators in modular layer(s)

This is a quick fix that corrects numbering of scintillators in modular layer to conform with convention we are using in Framework configuration - IDs of scins in modules start from 201.
Adding short macro for creating detector geometry with 3+1 layers by using a proper command.

I agree with the proposed changes. Furthermore, I suggest the minor modification when we split the modular layer into two layers. We may exchange the Scintillator ID's for the fourth and fifth layers. In this way, we will follow the layer sequence going from 3rd layer - 5th layer. I believe it just needs a small change in the code.

@pnp-sushil I think more systematic way of producing all the scintillators would be a good subject for separate PR for future version.
I general I was thinking about constructing detector based on same json file as we later use in Framework . This way we could keep the layer+slot structure we have as convention.
For now this PR is just a bug fix.


ship.rb: Remove SHA256 check

The developers are apparently pushing bugfix releases to the same URL. Current release according to the appcast is 2.0.2. I don’t think it makes sense to verify checksums for this cask.
Also see #29850 for the previous attempt at fixing this.

If there’s a checkbox you can’t complete for any reason, that's okay, just explain in detail why you weren’t able to do so.
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[ ] Named the cask according to the token reference.
[ ] brew cask install {{cask_file}} worked successfully.
[ ] brew cask uninstall {{cask_file}} worked successfully.
[ ] Checked there are no open pull requests for the same cask.
[ ] Checked the cask was not already refused in closed issues.
[ ] Checked the cask is submitted to the correct repo.

If it has an appcast, it will help us identify these better in the future.
Fixing correctly in https://github.com/caskroom/homebrew-cask/pull/30408.
Thank you for the report.

That's what I thought about doing as well, but your code will still break after each release until it is fixed, isn't it?

@lukasbestle It is, but it is still preferable to having version :latest and sha256 :no_check. See this for an explanation.


clarification on type LoadBalancer for exposing

Took me a bit of time to learn that type LadBalancer wasn't fully working in an OpenStack environment as I was going through this.

This change is

I signed it.

@rivimont Could you please check again with the instructions in https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ?

I signed it... There was a delay in receiving the CNCF e-mail but just agreed to the license.

@rivimont Perfect :) Thanks!

One more suggested edit for typos and missing spaces.

@bprashanth anything else needed to get this merged?

Added a commit to fix the remaining typos and misspellings ("cloudprovider," "loadbalancing," "loadblancing.")


Adding Power support(ppc64le) with ci and testing to the project for architecture independent

I am working for IBM to port cpu arch ppc64le for open sources.
This PR adds CI support for the IBM Power Little Endian (ppc64le) architecture. The idea is to ensure that the builds on this architecture are continuously tested along with the Intel builds (amd64) as this is part of the ubuntu distro
on that architecture as well and detecting (and fixing) any issues or failures early would help to ensure that we are always up to date.
This helps us simplify testing later when distributions are re-building and re-releasing,We typically build applications for customers and ISVs, and while we don't use this package directly, we do count on all of the packages in debian/ubuntu to build other packages. So we more likely have this as a second or third level dependency and couldn't tell you explicitly which features we use or our usage model.
Please help to verify and merge.

Rejecting for the same reason as https://github.com/jazzband/django-debug-toolbar/pull/1421 – let's discuss the merits there.


Solution for flikering nodes while overlapping each other

what can be a good solution to solve flikering the views, can we implement clustering in that case.?

I have same issue, can you help me ?

Same issue, anyone resolved?

I have this problem as well

This is commonly referred to as "Z-fighting" in 3D rendering, i have the same issue

I have this problem too, seems like Z-fighting is what we want to solve. Any lead please

Duplicate of #64


Replace GeckoLibMod.DISABLE_IN_DEV with a system property

The current approach requires mods wishing to disable the examples to load before GeckoLib.
This is impossible to consistently achieve for Fabric mods, as Fabric deliberately loads mod entrypoints in an arbitrary order relative to other mods.
Using a system property (via java.lang.Boolean.getBoolean(String)) would be a much better approach, as system properties can be set via VM launch arguments.

It's to keep the system the same in both Forge and Fabric. Version parity is a high requirement.

@AzureDoom
System properties are a Java feature, version parity would not be affected.
The current solution is literally broken in Fabric. If your mod happens to load after GeckoLib, you cannot turn it off.


Allow tsconfig.json when input files are specified

I don't know why the tsconfig.json is ignored even when the --project or -p option is specified.
In my opinion, the right implementation should be:

If no  --project or -p option: Ignore tsconfig.json
Otherwise: Use the configuration file specified. All the options used in the command line should overwrite the ones of the configuration file. E.g. The include/exclude keys of the tsconfig.json will be ignored when input files are specified.

I don't know why the tsconfig.json is ignored even when the --project or -p option is specified.

Could you provide a repro for a situation where tsconfig is ignored?

Sure @andy-ms , but I mean, this is not even a bug. This behaviour is explicitly explained in the docs: When input files are specified on the command line, tsconfig.json files are ignored.
When you do tsc file.ts -p tsconfig.json you get:

The lines of code are pretty easy to find
I just can't see why it's implemented this way.

Probably because no one's implemented it -- could you explain what the use cases are?

A pretty common practice is to have a pre-commit hook to lint only the staged files in your git project (It makes no sense to lint all the project).
If you try to create this hook that runs tsc over each staged file, you won't be able to use the tsconfig.json, as you are specifying some input files.

I have another use case for this. We have many projects that use typescript, and would like to reduce boilerplate and keep our typescript config in one place, so it can be uniformly applied across all our projects for consistency.
At the moment, there isn't a way to do this, since you can't specify both a glob of files to check, and an external path to a tsconfig.json file. The only workaround in the meantime is to copy/paste a tsconfig.json file into the root of every project and have it only contain an "extends" statement. This isn't the end of the world, but it's more boilerplate than we want.
This same goal is easily accomplished with TSLint, by using their --config option as well as a glob of files to lint. Is there any specific reason why it is disallowed by typescript itself? If not, I would be happy to take a stab at implementing it via pull request, just want to make sure its ok with maintainers.

related, but never considered #12958

I have a different use case that needs this as well. We have a pre-commit hook that does a quick type check (tsc -p tsconfig.json --noEmit). Currently it checks all the files specified in tsconfig.json, but it would be nice to only type check the files that were modified. We are currently using lint-staged to run linting tools on modified files, it would be great to only run the type check on the modified files too.
Like @brapifra said here, https://github.com/microsoft/TypeScript/issues/27379#issuecomment-424879463, it's written in the docs that this should be possible, but it clearly isn't.

ref #22649, #13575

We have some questions for everyone in this thread
Long story short, the real problem we see is that people make a tsconfig.json, then run
tsc someFile.ts

and get garbage confusing errors because e.g. their tsconfig specifies target: ESNext and the error says something like "This is an ES5+ only API, change your target!".
However, we're not sure what tsc someFile.ts means if there's a tsconfig present:
Question 1, do we:

Overwrite the files setting
Append to the files setting
Prepend to the files setting (order rarely matters but sometimes does...)

Question 2:

Are include and exclude still in play if there are some files specified on the commandline?

Question 3:

What if someFile.ts was in the exclude list?

Thoughts?

Just my two cents:

A pretty common practice is to have a pre-commit hook to compile only the staged files in your git project (It makes no sense to compile all the project).

This use case seems problematic in general, since TS needs to see your whole project for some things to work (e.g. const enum, namespaces), unless you use isolatedModules which disables those features.

Question 1.
I would expect that we'll "Overwrite the files setting".
Question 3.
If we'll treat someFile.ts as file to override files list, then no problem here - from the docs:

Files included using "include" can be filtered using the "exclude" property. However, files included explicitly using the "files" property are always included regardless of "exclude".

Question 2.
IMO include should be ignored in this case.
I think there is cases when some modules pollute global scope and it might break the compilation (because not all modules require that modules with globals even if they use them), but I believe developers should import deps explicitly (via triple-slash directives or even import statements in this case).

@RyanCavanaugh So, we will not be able to pass path to the custom tsconfig via --project CLI option? I believe it's a use case as well and it would be good to cover it too.

This can be hackily worked-around with jq (YMMV: probably lots of edge cases this won't work for, *sh only, and at this point you might prefer to write a wrapper js file which uses child_process):
tsc $(cat tsconfig.json | jq -r '.compilerOptions | to_entries[] | "--\(.key) \(.value)"') path/to/dir/**/*.ts

At very least we should have a way to tell tsc to use certain tsconfig.json, so I think -P, --project argument should work either way. And I agree with @timocov, overriding files with input should put the whole thing straight.

We have some questions for everyone in this thread

@RyanCavanaugh For my case, I would be fine if tsc would simply use tsconfig.json as normal for its work, but only print errors that occur in the files I’ve specified. I.e. it being simply a filter.
Perhaps it would be more explicit to have an option for that, but I don’t feel strongly about it.
$ tsc --show-errors-from=./src/Apps/WorksForYou/{**/,}*.{ts,tsx}

Hello. I too am on the same lint-staged / lint-prepush boat where I would like to have a git hook verify that a list of files pass the typecheck settings specified in tsconfig's compilerOptions.

Question 1, do we:

Overwrite the files setting
Append to the files setting
Prepend to the files setting (order rarely matters but sometimes does...)

I expect usage like tsc -p ./tsconfig.json myfiles.ts, for myfiles.ts to overwrite/replace the files setting. I would just like to "steal" the 20+ compilerOptions from tsconfig.json and get myfiles.ts typechecked instead of having to re-construct these compiler options in the CLI.
Thank you.

Any update on this? As it stands using tsc on a precommit hook isn't very viable for large projects.

I'm also in the camp that wants to run the compiler in a pre-commit hook.
Inspired by @mmkal's suggestion, I put together this simple node script: https://gist.github.com/dsernst/b1d2df3bb5be777e1dcb27e5c0d2474d#file-typecheck-js-L13
Example w/ error:

Otherwise:

Works great for my use-case. Hopefully others will find useful. :+1:

@JasonKaz try to declare external lint-staged config like here.
Then reinstall husky and lint-staged to avoid mistakes.

@JasonKaz, @Brapifra try to declare external lint-staged config like here.  Option -p ts.config.json can be omitted for root tsconfig.
Then reinstall husky and lint-staged to avoid mistakes.

Just wanted to throw another perspective in: a colleague new to TypeScript expected tsconfig.json to govern the transpilation of individual files as well, just as eslint reads .eslintrc when it's passed only one file to lint.

Hey, I've built https://npm.im/tsc-files which is a tiny wrapper on tsc to handle my need to type-check specific files with lint-staged. Hope it helps some of you.

I'm afraid my solution (https://npm.im/tsc-files) will miss type errors on other files. :disappointed:
For example, suppose changing foo.ts will break bar.ts. If you use lint-staged, only foo.ts will be type-checked (because it's the only staged file) and the type error that appeared at bar.ts won't be caught. If anyone knows how to fix that, please send me a PR.

There are explicit examples in https://www.typescriptlang.org/docs/handbook/compiler-options.html which show usage of --project and input files together... tsc --project tsconfig.json src/*.ts

@willstott101 Yes, it was mentioned above, but it doesn't seem to work. In fact, the new version of the documentation doesn't have that one example anymore: https://www.typescriptlang.org/v2/docs/handbook/compiler-options.html

Adding to the responses to the questions:
Question 1

Overwrite the files setting

Question 2

Ignore the include and exclude settings if files are specified on the commandline

Question 3

Not applicable due to answer to Question 2

We would find value in this for writing an arcanist tsc linter.
Please find below the use-case and workaround in case you need it
The way arcanist external linters work is by specifying an includes regex and then running your linter on every file that matches it. Tried pretty much everything, unfortunately, right now the only way to make tsc <file> type-checking work and handle tsconfig.json seems to write a runner (a.k.a tsc spawner). It works by:

specifying it to arcanist as the only file to type check in .arclint
runner will be called back as node <runnerPath/runner.js> <projectRoot> <runnerPath/runner.js>
on runner.js, parse args and spawn tsc to type the whole codebase

This way, tsc is called once, type-checks the whole codebase and handles tsconfig.json as it should.
.arclint
{
  "linters": {
    "tsc": {
      "type": "tsc",
      "include": "/^linters\\/.*\\.js$/" // runner.js is the only js file in our linters folder
    }
  }
}

linters/tsc/lint/linter/runner.js
function main() {
  // We don't end up using currentFile, refactor when 27379 is fixed
  const [, , projectRoot, currentFile] = process.argv;

  const { stderr, stdout, status } = spawnSync("tsc", ["--noEmit", "--jsx", "react"], {
    cwd: projectRoot,
  });
  // Do arcanist-related stuff with stderr stdout and status
}

Overall a similar use-case as the one @brapifra noted, and we would like not to be reliant on such a hack.

One more use-case is serverless Lambda functions.
It is convenient to have many related Lambda functions together in one project with common tsconfig.js and common reused utility code reused by some but not all functions. Given that every Lambda function has only one entry point – its handler – we can compile only this handler file and will get only files required to run this given Lambda function.
This not only allows to put less files into function's code, but (which is more important) to update only those functions that really uses changed code.
Example
Given following project structure:
── src
    ├── handlers
    │   ├── a.ts
    │   ├── b.ts
    │   └── c.ts
    └── utils
        ├── ab.js
        └── bc.js

By executing following comands:
tsc --project . --outDir .aws-sam/build/AFunction src/handlers/a.ts
tsc --project . --outDir .aws-sam/build/BFunction src/handlers/b.ts
tsc --project . --outDir .aws-sam/build/CFunction src/handlers/c.ts

I want to get following transpiled results that uses settings from tsconfig.json:
.aws-sam/build/AFunction
└── src
    ├── handlers
    │   └── a.js
    └── utils
        └── ac.js
.aws-sam/build/AFunction
└── src
    ├── handlers
    │   └── b.js
    └── utils
        ├── ab.js
        └── bc.js
.aws-sam/build/CFunction
└── src
    ├── handlers
    │   └── c.js
    └── utils
        └── bc.js

Workaround
Generate one-off child tsconfig files that overwrites includes property as described at https://stackoverflow.com/a/44748041
echo "{\"extends\": \"./tsconfig.json\", \"include\": [\"src/handlers/a.ts\"] }" > tsconfig-only-handler-a.json
tsc --build tsconfig-only-handler-a.json

As https://github.com/AkhmadBabaev mentioned here https://github.com/microsoft/TypeScript/issues/27379#issuecomment-586714352
This worked for my project:

tsconfig.json in project root
use lint-staged.config.js
omit -p tsconfig.json from tsc command

// lint-staged.config.js
module.exports = {
  "*.{js,ts,tsx}": "eslint --cache --fix",
  "**/*.ts?(x)": () => "tsc --noEmit",
};

I end up with esbuild so far.

npx esbuild ./config/*config.ts  \
    --tsconfig=./config/tsconfig.esm.json \
    --outdir=./config-out \
    --format=esm \
    --out-extension:.js=.mjs

My use-case is that we have converted a messy JS codebase to TS, so there are thousands of type errors. We want to go through and clean them up gradually, over time.
This means that we can't fail the build in CI for errors running tsc for the whole project.
It also means that running tsc --watch to diagnose and fix errors is pretty useless, you have to scroll through a bunch of errors unrelated to what you're working on.
I would love to be able to run a command like  tsc --focus foo.ts bar.ts which will only show errors that occur in foo.ts or bar.ts (not even related errors in other files) – literally just filter the output of tsc by filepath.

My use-case has to do with Jest tests or npm run scripts invoked using ts-node.  In my tsconfig.json I have some non-default compiler options set (e.g., "strict": true, "target": "ES2021", etc.), as well as the use of a distoutput directory for the compiled JavaScript.  When Jest tests or ts-node runs a single.tsfile, it compiles with different options (i.e., the default options) than I have specified, and, worse, pollutes mysrc/**directory with a bunch of individual.jsfiles (since, by default, the TypeScript compiler outputs the.jsalongside the.ts` source).
In my opinion, if a project takes the effort to define a project-wide tsconfig.json, those settings should be used whenever tsc is invoked.  Command-line options to tsc at that point can/should override any conflicting setting in tsconfig.json.

This issue has hundreds of 👍 responses. In https://github.com/microsoft/TypeScript/issues/27379#issuecomment-523669786 @RyanCavanaugh asked important questions about how it should work. In https://github.com/microsoft/TypeScript/issues/27379#issuecomment-523812085 @timocov answered those questions, ("overwrite files setting") and got 9 👍 emojis and no negative responses. There was another response https://github.com/microsoft/TypeScript/issues/27379#issuecomment-555575862 from @moopmonster which gave the exact same answer, and got 24 👍 emojis.
@RyanCavanaugh's question appears to be settled.
I speculate that a PR would be welcome that simply implemented the "overwrite files" approach.

It will be really nice if TypeScript team puts time on this issue.
I've read TypeScript's tsconfig.json behavior, it says TypeScript tries to seek every relative file that imports "ns" if you import "ns" as below.
import * ns from "mod"

And if the TS compiler finds files which import "ns", it automatically includes them in its compiling even though you don't want them to be type-checked. So to me, it sounds like TS will eventually look at extra files which might not be the ones you modified.
We want the option to tell the compiler to check the specific files, about TS grammar only, Not checking every referencing file! 😱

@moonformeli

We want the option to tell the compiler to check the specific files

This exists and is called noResolve

i run this code for my precommit hook and i am facing the same issue
const childProcess = require('child_process');
const util = require('util');

const exec = util.promisify(childProcess.exec);

const getTSConfigPath = require('../utils/getTSConfigPath');

const run = async () => {
  let isIncludeFiles = false;

  const files = process.argv.reduce((result, arg) => {
    if (isIncludeFiles) {
      result.push(arg);
      return result;
    }
    if (arg === 'files') {
      isIncludeFiles = true;
    }
    return result;
  }, []);

  const queue = files.map((file) => {
    const tsconfigPath = getTSConfigPath(file);
    return () => exec(`tsc ${file} --project ${tsconfigPath} --noEmit`);
  });

  let error = false;

  const runQueue = (index) =>
    queue[index]()
      .then(() => runQueue(index + 1))
      .catch((err) => {
        error = err;
      });

  await runQueue(0);

  if (error) {
    throw error;
  }
};

run();

managed to solve the problem:
const childProcess = require('child_process');
const fs = require('fs');
const path = require('path');
const util = require('util');

const exec = util.promisify(childProcess.exec);

const getPackagePath = require('../utils/getPackagePath');

const run = async () => {
  let isIncludeFiles = false;

  const files = process.argv.reduce((result, arg) => {
    if (isIncludeFiles) {
      result.push(arg);
      return result;
    }
    if (arg === 'files') {
      isIncludeFiles = true;
    }
    return result;
  }, []);

  const queue = files.map((file) => async () => {
    const packagePath = getPackagePath(file);
    const tsconfigPath = path.resolve(packagePath, 'tsconfig.json');
    const tsconfigData = fs.readFileSync(tsconfigPath, 'utf-8');
    fs.writeFileSync(tsconfigPath, tsconfigData.replace(/"include": \[[\W\w]*\]/, `"include": ["${file}"]`));
    try {
      await exec(`cd ${packagePath} && yarn run tslint`);
      // eslint-disable-next-line no-useless-catch
    } catch (error) {
      throw new Error(error.stdout);
    } finally {
      fs.writeFileSync(tsconfigPath, tsconfigData, 'utf-8');
    }
    return true;
  });

  const runQueue = (index) => queue[index]().then(() => runQueue(index + 1));

  await runQueue(0);
};

run();

@basketball7hero the tsconfig include trick is neat, but I suggest to create temporary tsconfig file, rather overwriting project existing config and restoring it later.

Our ideal use case would be to use tsc for fast type checking only for modified files (lint-staged?) with the same logic as ESLint which takes into account the closest config file based on the file to check so that it can also be used in a monorepo project structure (we use Nx)

Our ideal use case would be to use tsc for fast type checking only for modified files (lint-staged?)

Yes please! 🙇♂ 🙏

How does VS Code generate red underline for TypeScript issues on individual files?

How does VS Code generate red underline for TypeScript issues on individual files?

I think it doesn't compile files individually. You just see those lines after Typescript has processed the entire codebase

any update here?

Same as others, this breaks my lint-staged configuration and took me hours to find out why.
I understand the ambiguity of tsc someFile.ts with a tsconfig file, i would maybe add just a flag for the most common use case which seems to be: run it as you run the folder and it was just an individual file)
Also two less ambiguous options:
A)  a -skipConfig or -skipProject or -force could force it against the tsconfig
B)  a flag to use the tsconfig on purpose, like just `tsc someFile.ts ../..tsconfig.json
I would probably do B so it has no regressions. Also that's the hallucinated solution that ChatGPT gives when asking why the tsconfig is not working and how to force it.

Btw this is a cool workaround: https://github.com/gustavopch/tsc-files

Hi everyone,
I’ve encountered the same issue discussed here and wanted to share a solution I’ve been working on. I created a project called tscw-config that addresses this problem. It allows users to run tsc with both files and tsconfig.json at the same time:

It provides CLI and API that you can use.
It seamlessly integrates with most popular package managers, including:

npm
pnpm
Yarn
Yarn (Plug’n’Play)

It is well tested.

Feel free to check it out and let me know if you have any feedback or suggestions!

Another use-case that I'm working on at the moment is in asset pipelines that process a single file at a time, such as Rails' Sprockets.  If I request a javascript file that is backed by a typescript file, I need to get just that single file, compiled on-demand (for development scenarios, where an updated typescript file should automatically be recompiled).  I would have the tsconfig.json to be a common place to store my settings, but still need files compiled one at a time.
I'm currently doing something similar to the tsc-files solution: building a temporary copy of the tsconfig.json and modifying that instead of using command line arguments at all.

I found my way here after a fair amount of confusion on my part. GPT was also confused about this, hallucinating all sorts of solutions that don't work. Glad to realize I'm not crazy after find this issue.
My use case is to write a simple pre-commit hook that checks only the files that have changed in my repo. We have a fairly large repo and running tsc on the whole repo takes about 10 seconds, a bit long for a commit hook.


[FP]: protobuf-java 4.x release candidates flagged with CVE-2022-3171

Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:com.google.protobuf:protobuf-java:4.0.0-rc-2:*:*:*:*:*:*:*
CVE
CVE-2022-3171
ODC Integration
{"label"=>"Maven Plugin"}
ODC Version
9.0.7
Description
OWASP Dependency Check is incorrectly flagging protobuf-java 4.0.0-rc-2 and 4.0.0-rc-1 with CVE-2022-3171. According to the CPEs currently published to the NVD, no 4.x releases of this JAR should be considered vulnerable. From the NVD:

A parsing issue with binary data in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack.

The CPEs all have an upper limit in the 3.x range so this appears to be an issue with ODC and not the NVD's data.

The 'OSSINDEX' suffix to the CVE in the report means that the researchers of OSSINDEX classified that library as vulnerable to the same issue. Whether or not that is valid is up to you to further validate and discuss with the people at OSSINDEX.
DependencyCheck validly reports that according to OSSINDEX vulnerability database the rc's are subject to the same CVE

The CPE links to https://ossindex.sonatype.org/component/pkg:maven/com.google.protobuf/protobuf-java@4.0.0-rc-2?utm_source=dependency-check&utm_medium=integration&utm_content=9.0.7
where OSSINDEX is indeed indicating the CVE applies to 4.0.0-rc-2 according to their dataset (visible after you login with a (free to sign-up) account)


Bugs and suggestions

iPhone 15PM, latest LLM FARM version (1.0.0).
Start with bugs:
1: Downloaded mobile VLM 3b model and clip model. Connect them together, set template mobile VLM. Import picture, write in prompt describe this picture. Get correct answer. Import another picture, ask same question, get answer with mixed both answer. Expect this, because the model remember the history. But, clean the chat history with eraser icon, insert another picture, ask the same question, but again, get mixed answer with both the latest picture.
Expected behavior: it will look only for the text on the window. But it still "remember" the history. You must reload the whole model.
2: With you generate text, you long hold on the generated text, there is copy, if you click it and paste it back to the prompt line, nothing is pasted (because nothing was copied).
3: When I edit the VLM model, where I added clip, the clip model doesn't show there and the clip switch is turned off. But when you click the switch, it will load the clip model. So it's there, only the switch is bugged.
Now suggestion:
1: It will be nice, when the text still generating, we can scroll up and read the beginning. Now it auto scroll and you cannot interrupt it.

Hi. Thanks for the feedback!
At the moment the clear history button does not really clear the model context. You can clear the context by using the reload model button next to the clear button.
You are not the first to comment on this behavior, so I will add context clearing when clearing history in the new version of the application.
About scrolling, I am aware of this problem and as soon as I get my hands on it I will solve it.

Bug 1 and 5 solved.
Suggestion 1 partially solved.
When generating text, you cannot scroll the text when keyboard is open, but when you close it with tap, after you can freely scroll it while generating and even when you reopen the keyboard, you can scroll the text.


[BUG]: Unique key reconciliation with upstream schema is inconsistent

What version of drizzle-orm are you using?
0.31.2
What version of drizzle-kit are you using?
0.22.8
Describe the Bug
Unique keys aren't able to be reconciled properly using Drizzle with PlanetScale MySQL.
We have unique constraints defined using Drizzle Orm, either through the primary key constructor, or through specific unique key constructors i.e
id: serial('id').primaryKey(),

or (and see my comment above the code)
/*
	- this will always cause an error to throw when running yarn db:push against your feature db
	- your changes should get any other changes you've made should be applied anyway
	- think its an error with the drizzle push command not reconciling the constraint properly
	*/
  email: varchar('email', {length: 255}).notNull().unique(),

We use DDL against feature branches in PlanetScale to create a schema change, then make a deploy request to PlanetScale.
A few things are happening:

When we push unrelated schema changes to our DB using drizzle-kit push --config=drizzle.config.ts - we get an error complaining the above constraint already exists i.e You're about to add users_email_unique unique constraint
When we make deploy requests after adding unrelated tables/column changes, we'll find that Unique Keys from random tables are being dropped

Expected behavior

Unique keys are able to be reconciled properly through introspection
Unique keys wouldn't randomly be dropped through DDL commands against our planetscale feature branches, through unrelated changes

Environment & setup
Node JS: 20.14.0

thanks, taking that into work

@AndriiSherman anything I can do to support on this front?


Bump libcni version

Pull Request Test Coverage Report for Build 640397690

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 70.766%

Totals

Change from base Build 638587149:
0.04%

Covered Lines:
1145

Relevant Lines:
1618

💛  - Coveralls


Suggestion - add link to pricing page

:wave: It took a little effort to understand if the official API required payment, it seems up to 1000 conversations/month are free, then there's a charge:
https://developers.facebook.com/docs/whatsapp/pricing/

Thanks Andy 🙌 https://github.com/ignacio-chiazzo/whatsapp_sdk/pull/14


Add a ramMin ResourceRequirement to Filter VCF MapQ0

https://github.com/genome/analysis-workflows/blob/5a4fed24f01f6d7c7ce1f595b272d82d97d4f9bd/definitions/tools/filter_vcf_mapq0.cwl#L6
Example:
    - class: ResourceRequirement
      ramMin: 8000
      tmpdirMin: 100000

closed by #577


[KYUUBI #3080][DOC] Add a doc of the Flink Table Store for the Trino SQL Engine

Why are the changes needed?
Add a doc of the Flink Table Store for the Trino SQL Engine
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

thanks, merged to master


Is there a way to add preset names to file outputs?

Your question
In the docs, it says to put [some parameter name here], but whatever name I try in the OutputPathBuilder doesn't work. I've tried [presets_used], [presetsused], [presetname]. [presets] and [preset_name].
Speaking of presets, could there be a way to sort them?
Logs
No response
Other
No response

re out path: currently no, they're tracked a bit weirdly, so that's a needed feature to add that.
Re sorting them: what do you mean?

I meant being able to drag them or some kind of option to sort them alphabetically. New presets are always put last, and Swarm jumbles up the ordering of imported csv files for some reason, which can make them hard to find.
In a1111, I'd just edit the styles csv to change the ordering. Does Swarm have a file where the presets are stored I could edit? The only files I can find related to presets look like scripts and stuff.

You can now use [presetsused] or [presets_used] or whichever to read presets in the output path.
For the sorting thing, make a separate feature request

Awesome, thanks :D