noEmit should be on by default in TS compiler options

This is a related issue to #352. The build script works with rollup.js, not tsc, so the noEmit option should be enabled by default. Users running npx tsc shouldn't expect to have to specify --noEmit, because using tsc is a normal part of TS development. Currently npx tsc will clutter the src directory with transpiled files, which can be difficult to clean up if there are uncommitted changes mixed in.
This is important because without tsc there is no way to do project-wide type checking. The build script will only stop at the first error. The test runner will report errors, but only for files that are tested, and it's also the wrong place for type checking (#521).

Do you mean turning it on by default in the templates? Or in the build command itself?
I think your intent here is to have type-checking separated from build (or test), which makes sense to an extent.
But changing tsconfig.compilerOptions.noEmit to true would be very unexpected. The build command should emit by default, not just report type errors by default -- that is how build tools work after all, including tsc itself.
In either case, that would be a breaking change. I think #352 makes more sense than this, but #352's change doesn't actually align with how ESLint works.
An intermediate change would be to change the templates such that the lint script runs tsc --noEmit && tsdx lint. That way a workflow isn't being forced upon users (they can change it/it would be merely a recommendation) and tsdx lint isn't different from ESLint's behaviors.
Misalignment with the underlying tools & their integrations is already an increasing issue with TSDX (#514, #498, some on testing too), and that misalignment is very confusing and unintuitive, so I don't think further misaligning by changing tsdx lint itself is a good idea.
Another option is to have another command like tsdx tsc, but I have a feeling that would cause more issues than it solves.
You can also run tsdx watch --noEmit for something similar to what you're looking for.

it's also the wrong place for type checking (#521).

Again that's an opinion... Doesn't matter how many times you repeat it, it's still an opinion. ts-jest exists and has its defaults as such for a reason.

tsc is primarily a type checking tool that can also transpile. I don't see how it emitting transpiled files into the source directory (not the build directory) would be useful, particularly when the actual build uses Rollup.js instead, or for what users it would be a breaking change.
I forgot to mention that besides noEmit it also requires skipLibCheck, since otherwise tsc can fail when checking dependencies in node_modules.
Currently tsdx build fails on the first error, so if you want to fix all the errors so that the build would pass, you need to run tsc. Without noEmit, it's essentially a trap, since it creates many files in the source directory, requiring something like git clean -f to resolve.
There are also type errors in the test runner, but not necessarily for all files. It's an opinion that the test runner should just run tests instead of checking types, but it's well-grounded, so I'm repeating it.
Currently, to check all the source files for type errors, it requires knowing to run tsc with one or two flags, otherwise it will create an inconvenience for the user or possibly fail with a false positive.
Notably, the create-react-app TS template has noEmit and skipLibCheck enabled.

tsc is primarily a type checking tool that can also transpile

Well considering --noEmit is a flag, I don't think the TypeScript team would agree.

I don't see how it emitting transpiled files into the source directory (not the build directory) would be useful, particularly when the actual build uses Rollup.js instead, or for what users it would be a breaking change.

Sorry maybe this wasn't clear -- tsconfig.json configures both TSDX and tsc. That's where the issue is.
That's also why I asked if you meant templates or build command itself. Just changing the templates' tsconfig.json means that tsdx build would also not emit by default.
We can override tsdx build to always emit and then set the templates to have noEmit, but that override would be breaking to users that configure noEmit for TSDX. It's probably not a huge number of people, but it is breaking.
You pointed out a separate issue here that outDir should probably be set to ./dist/ by default in the templates. Though TSDX doesn't currently handle that config option too well (there's a few issues on that and I have a like 3 month old PR on this that still hasn't been reviewed) so it's not really "configurable" right now.

it also requires skipLibCheck, since otherwise tsc can fail when checking dependencies in node_modules

I don't actually have experience with this flag, but afaict this skips checking all declaration files, including ones you may have created yourself. You'd want the ones you created to be checked.

Currently tsdx build fails on the first error, so if you want to fix all the errors so that the build would pass, you need to run tsc

Yea you mentioned this and I guess I never really noticed this. It sounds like it would be good if outputted all errors, so I'll look into that.

Without noEmit, it's essentially a trap, since it creates many files in the source directory, requiring something like git clean -f to resolve.

Yea, that's unexpected/bad. See outDir comment above. That would fix this issue.

Notably, the create-react-app TS template has noEmit and skipLibCheck enabled.

This is a good example, especially since TSDX has borrowed pieces of CRA before. I don't know how long it's had those options; there might be a reason why Jared didn't stick with them. I know CRA reads tsconfig.json (#489 uses similar code) but I'm not sure how much of it is overridden if any (particularly for dev vs. prod builds). That may be where the difference is, will have to look.

noEmit has no effect on tsdx build because tsdx uses Rollup (rollup-plugin-typescript2 just checks types and transpiles). tsdx build completes fine with noEmit set to true. outDir should not be set and insted emitting with tsc should be disabled because tsc is not used as the build tool, but Rollup is. Rollup or webpack are specialized build tools and so are preferable to tsc because of all the features and plugins they have. That's why tsc is primarily a type checker that can also transpile, but it isn't used for transpiling in more advanced contexts.
skipLibCheck being disabled makes type checking fail if there are type errors in dependencies. Having to fix  dependencies in node_modules to pass type checks is almost never what the user would want, and it's also not what tsdx build currently does. tsdx build also doesn't check the ambient declarations.
Not having skipLibCheck also makes builds unnecessarily slower; just tsc --skipLibCheck on my test project takes 3s, just tsc takes 10s, and tsdx build takes 30s. This is also why type checking shouldn't be coupled to building, because it delays feedback.

noEmit has no effect on tsdx build because tsdx uses Rollup (rollup-plugin-typescript2 just checks types and transpiles). tsdx build completes fine with noEmit set to true.

I didn't know this, but rpts2 apparently forces noEmit to false. I thought turning it to true would be the equivalent of a dry-run but I guess it's just ignored.
So yea, then you're right, this wouldn't be breaking. Would you like to make a PR to add noEmit to the templates? Would have to add:

to each template
a comment next to this option saying something like // this is only for type-checking with tsc, tsdx build forces this to false
possibly a typecheck script? (and related docs). would just run tsc

outDir should not be set and insted emitting with tsc should be disabled because tsc is not used as the build tool, but Rollup is.

The templates can be reconfigured as a user wants, so ideally outDir should be set as well so that if they remove noEmit or something they don't fall into the trap. Also because I'm working on making the ability to change outDir.

Rollup or webpack are specialized build tools and so are preferable to tsc because of all the features and plugins they have. That's why tsc is primarily a type checker that can also transpile, but it isn't used for transpiling in more advanced contexts.

I don't disagree that they have lots of features and that in TSDX's case, tsc would just be a type checker. But lots of projects use tsc directly to compile, and even Rollup users use tsc:  https://github.com/ezolenko/rollup-plugin-typescript2/issues/189 . This is off-topic in any case.

skipLibCheck being disabled makes type checking fail if there are type errors in dependencies. Having to fix dependencies in node_modules to pass type checks is almost never what the user would want

https://github.com/facebook/create-react-app/issues/5738#issuecomment-437562588 confirms that all type declaration files get skipped if this is disabled, including internal ones. I'm not sure I agree with the position that a user would "almost never" want this. If there are type errors in your dependencies, that's a problem and you should fix that (by upgrading or overriding etc). TSDX itself has an internal declaration file. This file wouldn't be type-checked if skipLibCheck is disabled.

it's also not what tsdx build currently does. tsdx build also doesn't check the ambient declarations.

Huh, weird I just confirmed that myself. It's not mentioned in rpts2's docs, so this might be a bug actually.

Not having skipLibCheck also makes builds unnecessarily slower; just tsc --skipLibCheck on my test project takes 3s, just tsc takes 10s,

I'm not sure I would characterize this as "unnecessarily" slower, it checks things that might not be correct, including any of your own declarations.
It is a big hit, but shouldn't be big overall when watching for incremental changes during development, and for production it seems quite useful.

So, you're a user, you get a type error in a dependency in node_modules that you don't control, and your build fails; what are you supposed to do? There wouldn't even necessarily be a straightforward patch; it might be a conflict in complex typings, or an issue with generated files (meaning that you would have to delve into the build setup of some other project to fix it, or patch generated files), etc. Remember that this makes the build fail on top of being slower.
Moreover, the ambient declarations are typically already checked at authoring time; the reason why skipLibCheck exists is because the declarations are typically already known to be correct and don't need to be checked every time.

… shouldn't be big overall when watching for incremental changes …

Incremental builds are a specific feature in TS (the incremental compiler option), and they would require noEmit to be false, and emitDeclarationOnly with a temporary outDir (that's also in .gitignore). I didn't propose it since it's more complex (the outDir needs to be unused, for example, to avoid conflicts), but it might be a good idea; it's what I use myself.
The other kind of incremental checking is watch mode, but that's only appropriate when working on something for an extended period, and even then it should be normal to check the types for the rest of the project manually, since the editor would already check the files being edited.
Your example declaration file in tsdx has essentially nothing in there to be checked (it's actually broken, but in an inconsequential way; it's not detected because tsdx itself uses skipLibCheck). For the projects that do something advanced in ambient declarations, there are special tools like tsd or dtslint. Those are advanced use cases, however.
skipLibCheck also makes the type checking noticeably slower; it slows it down several-fold for the projects that I've timed it with.

Are you saying the correct thing to do is to... ignore it??
skipLibCheck makes for less strict typing and TSDX currently has tsconfig.json set to most strict (which I believe is optimal)
I think it makes more sense to either explicitly override the types or patch or upgrade to a newer version or file an issue or check if there is a workaround available.

Moreover, the ambient declarations are typically already checked at authoring time; the reason why skipLibCheck exists is because the declarations are typically already known to be correct and don't need to be checked every time.

The keyword here is typically. An author may also have less strict typings than you might. And they may have hand-written the declarations and didn't check them.

Your example declaration file in tsdx has essentially nothing in there to be checked

It's really easy to accidentally have a type error when hand-writing declarations. And it wouldn't be checked.

(it's actually broken, but in an inconsequential way; it's not detected because tsdx itself uses skipLibCheck)

Welp, well that's ironic. One of those things that pop up when it doesn't dogfood itself: #381

skipLibCheck also makes the type checking noticeably slower; it slows it down several-fold for the projects that I've timed it with.

Based on my reading, that's the primary reason it exists, yes. I don't think trading off strictness for a performance optimization should be the default case. You can always re-configure it, but strictness should be default.

and even then it should be normal to check the types for the rest of the project manually, since the editor would already check the files being edited.

Not totally sure what you're trying to say here.
My point was that the performance penalty will only happen on the first build if using any form of incremental checking, and watch mode is the default script for yarn start.

Options for incremental builds:

I'm not sure what the purpose of emitDeclarationOnly and skipLibCheck are  here? They're not necessary for incremental to be used.
In any case, the requirement of setting outDir makes this difficult to have as a default since outDir will be configurable soon inside of TSDX and is already used by rpts2. Would need to have something like split dev/prod tsconfigs.

I'm still ok with the noEmit option being added in a PR as I said previously. The rest of this is kind of a separate issue.

Are you saying the correct thing to do is to... ignore it??

If the build is failing due to external typings, the main actionable fix will be to disable checking them, and it particularly makes sense since the errors may be spurious and/or have no impact (like the tsdx declaration error, or the errors that allowSyntheticDefaultImports was created to ignore). Filing an issue or looking for upgrades in many cases will amount to wishful thinking.
Declaring strictness as an end in itself is not a serious approach; it depends on the specifics.
The incremental compiler option requires emitting, and since the actual build artifacts are created by Rollup, emitDeclarationOnly is a way to cache just the declarations, and I included skipLibCheck since it's part of the difference from the current config. yarn start doesn't factor into it since it's not suitable for type checking due to being slower and incomplete. Not having to wait unnecessarily for common tasks is a significant part of a good developer experience.
I've found that I should explore alternatives to tsdx that would be guided by better experienced input.

If the build is failing due to external typings, the main actionable fix will be to disable checking them

That is one possible fix, not the only one. And it is a very overbroad one at that, as it disables checking all declaration files. And, again you can change your tsconfig.json to disable skipLibCheck if that's the solution you want to use.

Declaring strictness as an end in itself is not a serious approach; it depends on the specifics.

We're talking about defaults here. Again, you can change your tsconfig.json however you want.

The incremental compiler option requires emitting, and since the actual build artifacts are created by Rollup, emitDeclarationOnly is a way to cache just the declarations

Ok, I'm confused -- I thought you meant using incremental as a way to speed up type-checking with tsc not actual production builds.

Not having to wait unnecessarily for common tasks is a significant part of a good developer experience.

I agree that's not necessary for type-checking, which is why I've said a few times now I would support noEmit and possibly a typecheck script.

I've found that I should explore alternatives to tsdx that would be guided by better experienced input.

Ok sure. Again, you can reconfigure TSDX however you want. The defaults don't seem to align with your opinions, but those are, again, opinions, and again, don't seem to be widely supported by other users.
Also the defaults for most users may not necessarily be the best for very advanced users (who likely have their own configs), those are two different workflows.

Ok, I'm confused -- I thought you meant using incremental as a way to speed up type-checking with tsc not actual production builds.

It's clearly not a production config since it emits only the declarations (as a cache for the incremental option to work), and the outDir is in .cache.
As for opinions: not all opinions are the same; they differ by being well-grounded and informed or not. Even facts require interpretation. I'm not saying anything that would be akin to stating my favorite color; it's about what would be common scenarios for the user. Having faster type checking and not having builds break because of reasons outside of the user's control benefits the common case. Having complex types in ambient declarations is an advanced case. The suggestion that skipLibCheck would be optimal for advanced cases or specific to my workflow is the opposite of what's being said.
Here's the PR adding skipLibCheck to CRA that states the same rationale, and it also links to issues where users ask for it due to performance reasons. I found one comment in their repo where a user turned on skipLibCheck due to needing to check the ambient declarations.
The TS repo has many examples of complex issues with 3rd party typings (random example). Here's a good SO answer detailing the reasons for it. The issue highlights type conflicts (different dependencies typing shared APIs), but there can be other issues; here's an odd error from my own library; it's unclear how to fix it since it uses a standard config and doesn't do anything special.
I'm looking at alternatives since these discussions are unnecessarily taxing; it shouldn't need to be explained that strictness shouldn't be an end in itself, particularly not in the context of popular tooling in a complex ecosystem.

This is a really good discussion. Learned a lot about TS!
A bit of history, when I made TSDX I made one change to how Formik’s build system worked: rpts2. OG pre-tsdx Formik used to use a two-step build (because Babel TS didn’t really exist yet). First it would use tsc and emit esnext js to a temp directory. Then rollup would bundle the temp directory to dist (so it could use Babel plugins). It’s very possible that I incorrectly kept around some TS config options that became redundant by switching to rpts2 but never noticed because “it just worked.”
—
FWIW, my course of action with libraries and apps differs with respect to incorrect dependency types. When writing an app, I will 100% use patch-package to fix the types. I want to check my deps. During dev/watch, I’m fine with foregoing dep checks on large projects, but prefer it if possible. During builds, I want as much type safety as possible. When making a lib, however, I don’t think patch package is acceptable. So I usually will fork the dep and publish my own corrected version or copy it into my libs source (with proper correction) if it’s small enough. Until reading this thread, I never considered skiplibCheck for libs, but maybe I should have. I usually err on the side of strictness and correctness over build performance.
—-
I think the question we want to answer is what the default behavior should be for novice and intermediate typescript folks. We will obviously have to document this somewhere in an “advanced config” section
cc’ing typescript team for their suggestion @orta
tl;dr we are debating what defaults should be for noEmit, skiplibCheck, incremental builds, and emitDeclaration given how rollup-plugin-typescript2 works.

It's clearly not a production config since it emits only the declarations (as a cache for the incremental option to work), and the outDir is in .cache.

You said this about emitDeclarationOnly:

and since the actual build artifacts are created by Rollup, emitDeclarationOnly is a way to cache just the declarations

If it's not for production anyway, then why cache just the declarations? Can't you just cache all the dev artifacts? Or are you saying incremental type-checking is faster when using emitDeclarationOnly? Sorry, it's not clear what you meant, hence confusion
I'd think there's more metadata for perf reasons when producing everything, but idk how it works under-the-hood and have not tested this. You didn't specify, so I'm not sure.

Here's the PR adding skipLibCheck to CRA that states the same rationale, and it also links to issues where users ask for it due to performance reasons.

Thanks for providing an example. The only rationale there is performance though (not ignoring errors) and the central topic of https://github.com/facebook/create-react-app/issues/5820 is actually around async for ForkTsCheckerWebpackPlugin, which couldn't be configured externally, unlike skipLibCheck.
Async type-checking would be good to have here too -- there is #151 for that and the upstream issue in rpts2.
But again, if you need the performance, you can always configure skipLibCheck to false. Nothing is preventing anyone from doing that. And again, incremental/watch performance shouldn't suffer much on average from it being true.
TSDX users so far have rarely complained about performance, so I think the priorities differ here. For library builds, I would certainly at least think that safety outweighs build performance.

The TS repo has many examples of complex issues with 3rd party typings (random example). Here's a good SO answer detailing the reasons for it. The issue highlights type conflicts (different dependencies typing shared APIs), but there can be other issues

Yea, I tried to do my research on it and have seen many of these myself, so I understand this issue has pretty broad scope in the community.
I've read the exact same SO answer and notably that one says:
"--skipLibCheck degrades type checking, and ideally we wouldn't use it. But not every library provides perfect types yet, so skipping it can be nice."
The takeaway I got from it was that It says enable only if needed, not use as a default.

here's an odd error from my own library; it's unclear how to fix it since it uses a standard config and doesn't do anything special.

That is pretty weird and I see how that's an issue (might be worth filing with TS). Though your library seems to be written in TS and has a type issue when used, which seems to contradict the assertion that everything is ok "at authoring time"?

Filing an issue or looking for upgrades in many cases will amount to wishful thinking.

That's again, not the only way to fix, but #542 is a counter-example

I'm looking at alternatives since these discussions are unnecessarily taxing;

Not for nothing, but I am an unpaid volunteer and you've made many remarks that I feel are condescending. I've been trying extremely hard not to respond to that. I even stepped away from responding to your issues because they were negatively impacting my mental health. I also did not want to respond negatively back to you.
You also haven't exactly made it easy to accept your opinions on top of that. If you immediately provided lots of evidence and statements from the community, it'd be much easier to take your side.
You made some faulty comparisons and some of the examples you provide contradict your own opinion. Some of these issues aren't well supported either, e.g. your ts-jest issue has 0 up-votes after being around for 1.5 years, and the TSDX issue has actually been down-voted. These make me much more cautious.
The CRA issue in contrast had 45+ up-votes.

it shouldn't need to be explained that strictness shouldn't be an end in itself, particularly not in the context of popular tooling in a complex ecosystem.

Once again, this is completely configurable, and this merely a default. tsc --init does not set skipLibCheck: true either. That is the most popular tool. And it does set strict: true. TypeScript was built for safety and its defaults err on the side of safety.

It’s very possible that I incorrectly kept around some TS config options that became redundant by switching to rpts2 but never noticed because “it just worked.”

@jaredpalmer this is more around missing options and a few of these are dev/type-check mode only. But #538 has a bit on options in the example template that might make sense to change.
skipLibCheck not working in rpts2 is the topic of https://github.com/ezolenko/rollup-plugin-typescript2/issues/212.
The big issues with the config have actually historically been around things like target , paths, and rootDir 😅

FWIW, my course of action with libraries and apps differs with respect to incorrect dependency types. [...]

Thanks for giving another perspective!

I think the question we want to answer is what the default behavior should be for novice and intermediate typescript folks. We will obviously have to document this somewhere in an “advanced config” section [...]

👍 👍 👍  Would be great to get TS team's thoughts since I'm getting mixed messages from what I'm seeing.

tl;dr we are debating what defaults should be for noEmit, skiplibCheck, incremental builds, and emitDeclarationOnly given how rollup-plugin-typescript2 works.

In a quick summary:

noEmit totally makes sense in TSDX's case for type-checking only, since that's the only thing you'd be using tsc for
incremental and emitDeclarationOnly are also around dev/type-check mode; which is faster and incremental vs. watch mode
skipLibCheck is the big debate here, for both prod and dev mode

Can't you just cache all the dev artifacts? Or are you saying incremental type-checking is faster when using emitDeclarationOnly? Sorry, it's not clear what you meant, hence confusion

tsc requires emitting for incremental to work, otherwise it errors out:
Option 'noEmit' cannot be specified with option 'incremental'.ts

The only rationale there is performance though …

The linked PR mentions that lib errors are "generally outside the users' control to fix".

The takeaway I got from it was that It says enable only if needed …

The defaults for a preset meant for the general use case depend on what the general case use is, and the answer doesn't comment on that.
The general case arguably is that users won't author complex ambient types, and that errors in library types can be spurious, and that enabling skipLibCheck will typically be the solution that makes the most sense.

Though your library seems to be written in TS and has a type issue when used, which seems to contradict the assertion that everything is ok "at authoring time"?

It's an example of a spurious error, and it doesn't come from a declaration written by me, but from tsc output.
What I meant by declarations being checked at authoring time is that people writing complex ambient types (like for Definitely Typed) wouldn't do it without type checking.

That's again, not the only way to fix, but #542 is a counter-example

The point is that the user's build would be breaking, and even if they filed an issue, the fix would be delayed and not guaranteed. In this particular example the type error also was trivial and had no actual impact, but would still have broken the build.
As for the rest, a lot of the confusion could have been allayed by taking a more charitable or careful reading and holding off on guesswork.

tsc requires emitting for incremental to work, otherwise it errors out:

Yes, I understand that and you've said that before.  My question was if emitting, why emitDeclarationOnly instead of emitting everything.
You said to set emitDeclarationOnly because tsdx build has its own build process, but those are separate cases, one is for dev type-checking and the other production builds.

The linked PR mentions that lib errors are "generally outside the users' control to fix".

Sorry, I should've used the word "main". The issue is focused on perf (primarily with async mode) and the subject of the PR is perf. As in, your focus seems flipped from theirs.

The general case arguably is that users won't author complex ambient types, and that errors in library types can be spurious, and that enabling skipLibCheck will typically be the solution in case of any library errors that makes the most sense.

What I meant by declarations being checked at authoring time is that people writing complex ambient types (like for Definitely Typed) wouldn't do it without type checking.

Ok, so it sounds like you indeed are suggesting that it should be disabled for the vast majority of usage, and only enabled for DT authors and the like.
This despite that there being no guarantee the typings aren't buggy, that there are independent tools for that, and that tsc's default is enabled. I don't think the SO answer or tsc are aimed primarily at DT authors.
I understand what you're saying about spurious errors, perf, etc, but there's a big misalignment there. A TS team member could clarify that.

The point is that the user's build would be breaking, and even if they filed an issue,

All I had to do was upgrade patch versions to get a fix. And, as I've said before and as with Jared's workflow, upgrading and filing issues are not the only solutions.

could have been allayed by taking a more charitable or careful reading and holding off on guesswork.

Yea, I don't know why I'm responding. Continued condescending remarks are abusive. I did not call other libraries legacy when they are not, did not suggest others didn't read or were making guesses, and didn't make puns at others' expense, among other such comments:

Nominally, but CRA has a significantly better TS DX.

Yes, I understand that and you've said that before. My question was if emitting, why emitDeclarationOnly instead of emitting everything.

Emitting only the declarations is enough for tsc to work with incremental.

You said to set emitDeclarationOnly because tsdx build has its own build process, but those are separate cases, one is for dev type-checking and the other production builds.

tsdx build should obviously override emitDeclarationOnly to emit the full build instead of just the declarations.

As in, your focus seems flipped from theirs.

I've mentioned that it's also about performance from the outset. The incremental compiler option was added some months later than the CRA changes, and it's a cleaner solution to the performance issue, so that leaves the focus on errors in dependencies.

This despite that there being no guarantee the typings aren't buggy, that there are independent tools for that …

All @types packages are checked before publishing, so there are some guarantees there. Conflicts are a different matter, though.

And, as I've said before and as with Jared's workflow, upgrading and filing issues are not the only solutions.

The other solutions are involved and situational. You can make a fork, which you'd also then have to maintain, and which would require dealing with the other project's build setup, which may take manual steps and reading, and may have quirks. patch-package is not appropriate for libraries, just for apps, and it also increases the maintenance cost. skipLibCheck will be the go-to solution for most cases when the user just wants their build to pass, and when the error has no actual impact (like in the actual concrete examples mentioned so far).

Yea, I don't know why I'm responding, this is not healthy. Continued condescending remarks are abusive. I did not call other libraries legacy when they are not, did not repeatedly suggest others didn't read or were making guesses, and didn't make puns at others' expense, among other such comments: …

I've given the technical reasoning for what I've said (like why ts-jest should be seen as legacy in light of babel-jest, and why CRA provides better developer experience for apps), and also why it matters from the user's perspective. The confusion that this has engendered is not justified, however, and is in itself condescending, since the operating assumption seems to be that I've been unclear. The focus should be on what the use cases would be, and how tooling would improve the workflow for them, and not on personalia, so I'd ask not to direct more queries at me.

This thread winds through a few topics, so I'll give my ideas in short-form

I don't think [skipLibCheck](http://www.typescriptlang.org/v2/tsconfig#skipLibCheck) should be enabled for users by default, personally. The flag explicitly breaks some of the type system contracts and is available if you need it, but that should be edge-cases not for everyone.

I'm a believer in using babel for transpiling and ts for type-checking when dealing with web. As a pragmatist, you probably already have babel in the tree, and it keeps build tools consistent. I'm personally against having types checking happening in tests, because I wouldn't want them blocking running a test. Whether using ts-jest or ts-babel is generally

WRT incremental / build mode etc  - these are useful for when TS is emitting the .js files in composite projects - which probably isn't happening in your watch mode which needs to go through rollup?

the OP on noEmit makes sense to me, given that it would be surprising to me too to see a bunch of ts files.

We just had the weekly design meeting - which included a discussion on skipLibCheck - the gist is that the team has switched to generally recommend skipLibCheck as true to folks. We can't change the default behind the scenes though, that'd be a breaking change.
The reasoning is that most of the errors it handles for you are  generally covered by the DefinitelyTyped automation test suites, and times you might hit the issues it will be quite obvious.

@orta thanks so much for chiming in!! Does the team plan to change the tsc --init default (as that's not breaking)? Similar to how esModuleInterop defaults to true there.

I'm a believer in using babel for transpiling and ts for type-checking when dealing with web

For context, TSDX users are both web and node (including me) and the pipeline is actually TypeScript -> ESNext then Babel -> preset-env, so we use both.

I'm personally against having types checking happening in tests, because I wouldn't want them blocking running a test. Whether using ts-jest or ts-babel is generally

Thanks for sharing. As we've had some discussions on workflow, I am curious what workflow you'd recommend for general use library development. Running tests in one terminal and type-checking in a separate one? Something else?

WRT incremental / build mode etc  - these are useful for when TS is emitting the .js files in composite projects - which probably isn't happening in your watch mode which needs to go through rollup?

I believe @slikts was referring to use it solely for type-checking with tsc, but I'm not totally sure. tsdx watch indeed goes through rollup.

the OP on noEmit makes sense to me, given that it would be surprising to me too to see a bunch of ts files.

I think we're all in agreement on that front 👍 I'm getting the sense that we should also add comments to some of our defaults in general to be more explicit for users

@orta any word on the above?

@orta pinging again.
I found https://github.com/microsoft/TypeScript/issues/37389, but that specifically says "not to turn it on by default" and doesn't elaborate on the discussions around what the default should be.
The v2 docs site on tsconfig also doesn't give any "Recommended" setting for skipLibCheck (e.g. strict has "Recommended True")

@orta one more ping

Yeah, the new plan for --init is to be this: https://github.com/microsoft/TypeScript/issues/37361#issuecomment-598867169
I've not yet updated any of the tsconfig settings for 3.9 - that's all

I don't see how it emitting transpiled files into the source directory (not the build directory) would be useful, particularly when the actual build uses Rollup.js instead, or for what users it would be a breaking change.

For some context, the TSDX users who use storybook (via the storybook template that TSDX provides) use the dist directory as a watcher that the storybook webpack dev server uses to refresh the page. So it's very useful for that use case.

@dgreene1 It sounds like you misread and misinterpreted that comment. 1. It's with respect to running tsc directly and 2. It says "the source directory (not the build directory)", i.e. running tsc directly will output co-located JS files instead of JS files into dist.
That is because neither outDir nor noEmit are on in the tsconfig.json. I'm looking to add support for these but tsc --noEmit doesn't yet type-check the entire templates (it only type-checks src), so I don't want to encourage its use just yet.

Looks like this was added to tsc --init in https://github.com/microsoft/TypeScript/pull/37808 and is now in the "recommended" tsconfig base (@tsconfig/recommended) so will be adding this to TSDX's templates as well.
It's not listed as "recommended" in the tsconfig reference though,  adding a PR for that momentarily

@allcontributors please add @slikts for idea, questions

@allcontributors please add @orta for questions, docs


Construct path for /.well-known/openid-configuration

Currently the well-known openid configuration endpoint constructs the url using Sprintf
https://github.com/semi-technologies/weaviate/blob/8ba795c5dbc1e2039ef3fa1bf53a023c0fd1a58e/adapters/handlers/rest/handlers_misc.go#L61
This causes issues if the issuer has a trailing slash (which is present in Auth0). Recommend to change from Sprintf to use net/url or similar to correctly handle trailing slashes i.e.:
target, err := url.JoinPath(serverConfig.Config.Authentication.OIDC.Issuer, "/.well-known/openid-configuration")

Great catch!

Released in v1.16.


Matrix multiplication for trainable weights

EDIT: it seems I was mistaken in my original question, but here's another one that spawned from it.
Is there a way for Keras to do matrix multiplication for trainable weights? (or in fact, a lot of operations)
For example,
LSTM_layer = LSTM(1, return_sequences='True')
output = LSTM_layer(input)
output = Lambda(lambda x: K.reshape(x, (1, 64)))(output)
self.w_attn_2 = K.variable(np.random.random((64, 64)), dtype='float32')
z = Lambda(lambda x: K.dot(x, self.w_attn_2))(output) # Need the lambda to maintain Keras tensor

It seems I would probably need to use custom layers for trainable weights for simple arithmetic.  It would be a lot easier if I didn't have to.

Operation you have outlined is just a Dense layer without bias.

@tRosenflanz yeah I noticed that earlier as well, but the actual model I'm building has expanding dimension, which forces me to use placeholders and tf functions, so I can't use a simple Dense layer here.
Anyway, the solution I ended up using is to create a custom layer in Keras, and use tf.matmul operation in there.


How to use pyiceberg to operate partition field and rename table

Feature Request / Improvement

How to use pyiceberg to add/drop/replace partition field
How to use pyiceberg to rename table

I used spark ddl before, but because of transaction, I want to use pyiceberg

Hi @madeirak for partition evolution, that will be released in 0.7 but if you wanted to try it out in advance you could install from source.
API docs on partition evolution: https://github.com/apache/iceberg-python/blob/main/mkdocs/docs/api.md#partition-evolution

Renaming a table is already supported via the catalog.rename_table API
https://py.iceberg.apache.org/reference/pyiceberg/catalog/#pyiceberg.catalog.Catalog.rename_table
So you'd do something like
from pyiceberg.catalog import load_catalog
catalog = load_catalog('your_catalog')
catalog.rename_table('db.table', 'db.renamed_table')

I'm going to close this for now since the above two points should cover your use cases but please feel free to reopen in case I missed something or if you have any more questions!


Model-show textfield without html tags

Laravel Version: 6.6.2
PHP Version: 7.2.19
Laravel-admin: 1.7
Description:
in model-show inside this field $show->field('description', 'Description'); I can see raw text with html tags on the page

Is it possible to do output showing the resulting text?

You can use the ->unescape() method which will display the value as intended.

cool. thanks!


fix: remove Components.sol

Motivation
Resolve #239
Solution

This PR removes Components.sol
#253 removes console2 usage in StdUtils.sol
Move some constants from CommonBase to TestBase and ScriptBase, depending on usage

Cc @paulrberg, I saw you use it in PRBMath.
Here's the reason why we removed it.

Thanks for the heads-up @ZeroEkkusu, and good catch. This is definitely counter-intuitive and odd. The Solidity team should know about this.


Merging dev -> master

Codecov Report

Merging #13 into master will increase coverage by 0.45%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   75.96%   76.41%   +0.45%
==========================================
  Files          45       45
  Lines         649      653       +4
  Branches       67       69       +2
==========================================
+ Hits          493      499       +6
+ Misses        127      126       -1
+ Partials       29       28       -1

Impacted Files
Coverage Δ

...rlton/bittrexapi/response/GetBalancesResponse.java
100% <ø> (ø)
:arrow_up:

...bittrexapi/response/GetDepositHistoryResponse.java
100% <ø> (ø)
:arrow_up:

...lton/bittrexapi/response/GetOrderBookResponse.java
100% <ø> (ø)
:arrow_up:

...harlton/bittrexapi/response/GetTickerResponse.java
100% <ø> (ø)
:arrow_up:

.../bittrexapi/response/GetMarketSummaryResponse.java
100% <ø> (ø)
:arrow_up:

...ittrexapi/response/GetMarketSummariesResponse.java
100% <ø> (ø)
:arrow_up:

...rlton/bittrexapi/response/CancelOrderResponse.java
50% <ø> (ø)
:arrow_up:

...bittrexapi/response/GetDepositAddressResponse.java
100% <ø> (ø)
:arrow_up:

...ton/bittrexapi/response/GetOpenOrdersResponse.java
100% <ø> (ø)
:arrow_up:

...ton/bittrexapi/response/GetCurrenciesResponse.java
100% <ø> (ø)
:arrow_up:

... and 9 more

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 a5ea0e2...8eb9ff3. Read the comment docs.


[sqlite-orm] cannot find package

Host Environment

OS: mac 10.15
Compiler: clang 11

To Reproduce
Steps to reproduce the behavior:

Run ./vcpkg install sqlite-orm
Add find_package(sqlite_orm CONFIG REQUIRED) to CMakeLists.txt
Run cmake

Failure logs
 Could not find a package configuration file provided by "sqlite_orm" with
  any of the following names:

    sqlite_ormConfig.cmake
    sqlite_orm-config.cmake

  Add the installation prefix of "sqlite_orm" to CMAKE_PREFIX_PATH or set
  "sqlite_orm_DIR" to a directory containing one of the above files.  If
  "sqlite_orm" provides a separate development package or SDK, be sure it has
  been installed.

Hi @algobot76
Thanks for posting this issue.
Since sqlite-orm does not provide an exported cmake file now.
So we cannot use find_package(sqlite_orm CONFIG REQUIRED) to find this library.
Maybe you can use find_path() and find_library() to find it.


PointerDownEvent and PointerMoveEvent default buttons to 1

Description

The unnamed constructors of PointerDownEvent and PointerMoveEvent now default buttons to kPrimaryButton (1), instead of 0.
Documentation improvement.

Reasoning

It is technically wrong for PointerDownEvent and PointerMoveEvent to have buttons = 0, which means their instances that are created out of the box are illegal.
kPrimaryButton is a good default value because it's valid in most cases for all devices.
Flutter has hundreds of instances of these 2 classes created in test files. If we don't change this, we'll have to change all of them (see https://github.com/flutter/flutter/pull/30408 as an alternative solution). In future PRs gesture recognizers will reject events with buttons = 0.

Related Issues

Tracking https://github.com/flutter/flutter/issues/30734
Alternative solution: https://github.com/flutter/flutter/pull/30408

Tests
No tests are related.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[x] Yes, this is a breaking change, it was proposed at https://groups.google.com/forum/#!topic/flutter-announce/M6J8oX1A17g and tracked at https://github.com/flutter/flutter/issues/30734

No objections have been raised by Apr 12th. Will try to commit.

Maybe add one test that checks the default value, so that people think twice before changing the default back.

Maybe add one test that checks the default value, so that people think twice before changing the default back.

@Hixie I've added the said tests


Re-enabling external tests

External tests is on the process of cleanup and update to make sure they will be running cleanly on many of the platforms for which we produce binaries. We'd like to enable them on supported platforms( docker supported). This can be done by two steps

[ ] enable on x86_64
[ ] enable on other xlinux platforms.

Todo this we need to

add sanity.external, extended.external to nightly or weekly testlist
limit the lists to specific platforms, which can be done by two ways:
- quick way: update function getTestList function to remove external category for non-supported platform
- feature added: add exclude testlist  keyvalue per platform  in jdk${version}pipeline_config.groovy file and update the getTestList function logic. This is actually adding a feature to support exclude specific test category per arch-os. Might be needed later, not sure it is necessary.

@LizyBbethy FYI

sanity.external on JDK11 xlinux https://github.com/adoptium/ci-jenkins-pipelines/pull/263


Release/v1.1.0

Please review docs.

docs/
CHANGELOG.md
README.md

1.1.0-rc2: https://circleci.com/gh/mattermost/desktop/240#artifacts

Fix the version string is 1.0.7
Fix the pixelated taskbar icon on HiDPI Windows

Anything holding this back?

Sorry for late. If possible, I will use rc2 and #100 as next release.


libcamera: rename bbappend to match the new filename

libcamera has been renamed in meta-openembedded in:
https://github.com/openembedded/meta-openembedded/commit/1032bce77885f20afb40fff4ed430167c75db59b
This patch is to rename the bbappend to match the recently changed recipe name in the above commit.

Should we rename bbappend to libcamera_%.bbappend to match any upstream package version?

Should we rename bbappend to libcamera_%.bbappend to match any upstream package version?

I agree. It seems more appropriate to change it as you said. I will update the PR. Thanks.

@agherzan Oh, sorry. I will squash the commit.

LGTM

@agherzan Please create langdale branch before this PR is merged, this will be the first change for mickledore (incompatible with meta-oe/langdale).

@agherzan Please create langdale branch before this PR is merged, this will be the first change for mickledore (incompatible with meta-oe/langdale).

Why would this be incompatible?

Why would this be incompatible?

Because of the filename.
libcamera_%.bbappend won't work with libcamera.bb (before rename from https://github.com/openembedded/meta-openembedded/commit/1032bce77885f20afb40fff4ed430167c75db59b)

@shr-project all done.


(feat): Performance Scale/Benchmark litmus experiment

Performance Scale/Benchmark litmus experiment

Scaling FIOs

Initial approach: Usage of ansible-based operator (operator-sdk) with an fio role to trigger fio jobs

This is available in an initial here: https://github.com/litmuschaos/litmus-go/tree/master/experiments/generic/pod-fio-stress


Update version and date PL RN

Update version from 1.26.11 to deployed version, 1.26.14
Update date in frontmatter for RSS feed

What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dde82643d48b1e7de3b7e5--harness-developer.netlify.app


fix(downloader): qdt_plugins_to_copy was not created in force mode

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 66.20%. Comparing base (58ba890) to head (6724399).

Files with missing lines
Patch %
Lines

...deployment_toolbelt/jobs/job_plugins_downloader.py
0.00%
1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #551      +/-   ##
==========================================
- Coverage   70.55%   66.20%   -4.35%
==========================================
  Files          47       47
  Lines        3124     3125       +1
  Branches      669      669
==========================================
- Hits         2204     2069     -135
- Misses        726      858     +132
- Partials      194      198       +4

Flag
Coverage Δ

unittests
66.04% <0.00%> (-3.93%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines
Coverage Δ

...deployment_toolbelt/jobs/job_plugins_downloader.py
50.37% <0.00%> (-0.39%)
:arrow_down:

... and 7 files with indirect coverage changes


Reduce minimum age on age filter.

Description
In RimWorld 1.4, it is possible to generate a colonist under 14 years old. Reduce the minimum possible minimum age on the age filter to reflect this change.
Possible solution
No response
Details
No response

Fixed in v6.2.0.


Trying to modify Code extension from mark to node

#510
CodeBlock is now parsed correctly when rendering to text.
Code on the other hand is almost impossible to correctly transform from Mark (that does not parse to text via renderText()) to a Node (that does parse to text via renderText())
It's frustrating to not be able to do such minor changes easily, leaving the code here if you want to have a look, I'm close but there is a tons of edge case still

This is pretty much what I would expect, marks seem borderline useless to me. I am working on moving the editor into welshman, so I may not merge this, but I will probably copy the changes over.

I've incorporated this into the editor refactor I'm working on.


purge raft log files with low utilization rate

For each raft group, log entries before compact index can be safely deleted. Although log entires are continuously written in most cases, but log entries of various groups are cross written.
e.g. :
file 1: | group 1, 0 - 100 | group 2, 0 - 50 | group 1, 101 - 200 | group 2, 51 - 100 |

As a result, with the system running, some parts of some log file can be purged but the other parts can not (e.g. 90% can be purged in file 1, 50% can be purged in file 2, we call the rate that can be purged of a file utilization rate).
So we can track the (approximate) utilization rate of each file, when the utilization rate of some files drops below the threshold, we need to rewrite the file (append the still needed part to the current active log file and update the memory indices of them) and remove the old log file. The rewrite operation is safe because we recorded term of the raft log and we can easily distinguish if log entries with the same index can overwrite the current one.
The rewrite procedure is asynchronous, and the follow aspects should be taken into consideration:

The utilization rate can be approximate or accurate, but the statistic should not affect the foreground writes much (e.g acquiring mutex).
The background rewrite throughput and frequency should be limited to prevent from affecting the foreground writes.
The threshold should be reasonable - neither too high nor too low.

cc @zackertypical


2.2.1 fails to run due to log file change

Summary
ClamAV fails to start - "ERROR: Can't open /logs/ in append mode (check permissions!)."
Possible fixes
"install\etc\cont-init.d\10-clamd" is still referencing the old log file variable when generating the configuration for ClamAV. Line 120 should read "LogFile ${LOG_PATH}${LOG_FILE_CLAMD}"

Thanks for reporting. I obviously was rushing when I was moving things around for 2.2.0 - A new :latest and :2.2.2 is available which will now write logs correctly.

Sorry - 2.2.2 still not working

The issue is in "install/etc/cont-init.d/10-clamd" (no changes made to that in 2.2.2) - LogFile on line 120 is wrong - referencing ${LOG_CLAMD_FILE} instead of ${LOG_FILE_CLAMD}
The 2.2.2 change was made to "install/assets/functions/10-clamd" - the additional forward slashes are not required (LOG_PATH ends with a slash) - don't know if they cause any other issues or if Unix/Clam handles that

Forgot to hit save :)
The double slashes shouldn't make a difference and are there more as a safety net for someone who may not pad the suffix of their LOG_PATH with one. Its ugly, but works. I have a way to solve it in future but now is not the time after 3 bumbled releases. Can you repull 2.2.2 ?

:) latest working now 👍
Thanks for a great container and for being so responsive.


Not working with Figma

After clicking "Send selection to Ae" the gray highlight animation going through the Send selection...button (which I assume means processing) keeps going, but nothing transfers to AE. I have AE open in another monitor, and it will bring that window into focus, but that's it.
I found this post on the Figma support forums suggesting to give full disk access to ZXP installer, but no luck even after a full remove and re-install of both the Figma and AE plugins
I wish I could give at least an error, but I'm not seeing anything. The one thing I noticed was that the Figma installation process is now different than described in the AEUX installation guide, but the Figma plugin still installed just fine with the current "Import plugin from manifest" option.

OS: macOS Big Sur 11.5.2
AEUX version: 0.8.0
Figma version: 101.6

I have a similar issue when I try to export a frame that contains images

@irispils the newest version (v0.8.0) should clear up the new issues with images. Any luck?

Hey @adamplouff, 0.8.0 is the version I have

Its not working for me either. IM a figma user in pc, after effects 2021

@irispils the newest version (v0.8.0) should clear up the new issues with images. Any luck?

Hey @adamplouff I did a fresh reinstall of both Figma's and AE's extension and it seems to work fine now. Cheers!

@irispils how did you do that? thanks,

@adamplouff @irispils I just tried reinstalling as well - I'm still having the same issue from before.

@sebaroach I manually replaced the plugin files for both Figma and AE, then restarted the programs. Hope it helps!

@adamplouff I'm getting errors when trying to export images as well - it wont pass to after effects and the console returns this:

@adamplouff I'm getting errors when trying to export images as well - it wont pass to after effects and the console returns this:

I get this exact issue as well. It pushes editable layers fine, but nothing works with the Asterisk

@Djsquid2020 Try 0.8.1-a. I just updated it to have the version number on the panel to be clear of the version currently running in Figma.

If that doesn't work, can you share your file with me<EMAIL_ADDRESS>

Wait! You're right. The problem was the * on the frame name. That messes with some stuff and should not be allowed to happen. I only caught the issue from your screenshot –thanks for that
I just posted 0.8.1-b which will now ignore * on frame names and add * to the children of a selected frame instead.

I'm also having this issue with AE 2021 and AEUX, my biggest complain it's that it seems there's no info on how to UNISTALL AEUX Plugin from Figma, anyone has some info? Thanks in advance!


Feature/some updates and fixes

Hi André
It would be great if you could make the review that it can be merged on the master branch.
Thank you very much!
cheers

Hi Lukas,  I will take a look ;)
Best regards,
—
[image: signature_1470162048]
André Duarte
CTO at Switch https://switch-ev.com/
LinkedIn https://www.linkedin.com/in/andrefilipef1/
The Ministry, 79-81 Borough Road, London SE1 1DN
On Tue, 6 Jun 2023 at 12:26, lukaslombriserdesignwerk <
@.***> wrote:

Hi André
It would be great if you could make the review that it can be merged on
the master branch.
Thank you very much!
cheers
—
Reply to this email directly, view it on GitHub
https://github.com/SwitchEV/iso15118/pull/232#issuecomment-1578535816,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC7PVFTMFT5XZ7KW4BVU4PTXJ4HWPANCNFSM6AAAAAAXVZ7L4U
.
You are receiving this because you commented.Message ID:
@.***>


LanePlanner: correct path offset for TICI

The model's path predictions are in the perspective of the EON/C2's left camera of -0.06 m, however with TICI it's treated as it's centered, but it should be offsetting the path extra 0.06 m to the right, this might be causing some minor left hugging.
Even if offsetting doesn't fully offset the path due to the model behaving unexpectedly with path offsets, since they were added at all I think getting it right is a good idea.
Or with the smaller offset are we sacrificing hugging for less path oscillation if the model behaves unexpectedly with path offsets?

I should have added comments to make this clear, but it is the way it is intended now. There are pretty complex effects at work. We look at the data from the model to see the average prediction difference between the model path from the TICI and C2 and that's how we get the current model path offsets.
Eventually we will input the camera offset into the model and it will all be a lot cleaner :).


Support signing publications

Goals
Make it possible (and easy) to sign publications created with the maven-publish/ivy-publish plugins.
Signing a publication should sign all artifacts (in particular the POM) within a publication.
There should be an easy way to make signing conditional, e.g. only sign releases.
Proposed DSL
signing {
    sign publishing.publications.mavenJava, publishing.publications.testFixtures
    // or even
    sign publishing.publications.matching { /* some condition */ }
}

tasks.withType(Sign) {
    onlyIf { /* isRelease */ }
}

@marcphilipp very much thanks, this is really amazing now and finally working easily as expected
I tried with the gradle-4.8-20180421000019+0000-bin.zip and it works great.
There is just one detail so far I found that is not too nice.
While playing around I still had old signature files lying around.
Yet I had no signatory for testing and required to false.
This caused the signXXXPublication tasks to correctly be SKIPPED.
The problem is, that the stale old and now surely not valid anymore signature files were published alongside the new artifacts.

I've verified that using the same problem is also present when using the old Upload-based publishing infrastructure.
@Vampire I've created #5136 to handle stale artifacts when publishing. Feel free to add more details to the issue. Since it's more of a corner case, we will probably not address it right away.

It's ok, just something I stumbeld upon and if I stumble upon something I usually either report it, fix it, or do both. :-)


wrapCallback is uncurryable

var foo = _.wrapCallback(function (thing, done){
  done(null, thing);
});

foo('bar').apply(_.log); // bar

_.curry(foo)('bar').apply(_.log);
//          ^
// TypeError: object is not a function

The issue is that wrapCallback handles its arguments dynamically.  I'm not sure there's any way around it, but I wanted to raise it for discussion as it would be a useful thing to be able to do.  I suppose _.partial could be used instead, but that's less elegant.
// _.wrapCallback
function () {
    var self = this;
    var args = slice.call(arguments);
    return _(function (push) {
        var cb = function (err, x) {
            if (err) {
                push(err);
            }
            else {
                push(null, x);
            }
            push(null, nil);
        };
        f.apply(self, args.concat([cb]));
    });
}

There's not really a solution for this. The only way of creating a function of a given arity at runtime is the Function constructor, which would have a huge performance impact.
A workaround would be to use _.ncurry with the expected length of the function:
var foo = _.wrapCallback(function (thing, done){
  done(null, thing);
});

foo('bar').apply(_.log); // bar

_.ncurry(2, foo)('bar').apply(_.log);

I suppose we could have wrapCallback save the original function length as a separate property (length isn't writable) that curry could then use, but that only solves this particular case.

What if we curried by default?  Seems within the spirit of this lib.
var wrapCallback = function (f) {
    return _.ncurry(f.length-1, function () {
        var self = this;
        var args = slice.call(arguments);
        return _(function (push) {
            var cb = function (err, x) {
                if (err) {
                    push(err);
                }
                else {
                    push(null, x);
                }
                push(null, nil);
            };
            f.apply(self, args.concat([cb]));
        });
    });
};

var foo = wrapCallback(function (thing, thing2, done){
  done(null, [thing, thing2]);
});

foo('bar')('baz').apply(_.log); // [ 'bar', 'baz' ]

Because the function being wrapped might have varargs. It's not in our control.
The only reasonable solution besides using ncurry is to have ncurry embed the length information in curried functions, which wrapCallback can use. So you can do something like this
var foo = _.wrapCallback(_.curry(function (thing1, thing2, done) {
    done(null, [thing1, thing2]);
}));

foo(''bar')('baz').apply(_.log);

This essentially saves you from having to figure out the length of wrapped functions that aren't varargs (lets you use curry instead of ncurry). But it'll only work on highland-curried functions. The semantics would be: curried function -> curried function out.

Good point about varargs.
Curried in -> curried out seems sensible enough to me.


SAK-48443 - Auto-expire users that fall off the the Plus roster

This has been running in my UMich production for a bit.


Missing Shebang

First line of google_images_download.py is
# In[ ]:

instead of
#!/usr/bin/env python

@knrdl Shebang line now added. Thanks!!
Closing this issue.


libtree-sitter-cedarscript.so: cannot open shared object file: No such file or directory

I am getting this error on python 3.12.6 - is there something I need to install? Should I just give up and wait for aider integration?
Failed to load native library:
/aider_venv/lib/python3.12/site-packages/cedarscript_grammar/libtree-sitter-cedarscript.so: cannot open shared object file: No such file or directory

You could try this inside the container:
pip install --upgrade --force-reinstall cedarscript-grammar

Thanks - I tried that after installing aider using the new in a new conda environment:
conda create -n aider_cedarscript_env python=3.12.6
conda activate aider_cedarscript_env
pip install git+https://github.com/elifarley/aider@cedarscript aider-chat
The command aider --model deepseek/deepseek-chat --edit-format cedarscript works and I see some CEDARSCRIPT being generated, but then the error: ``
I tried your suggestion:
pip install --upgrade --force-reinstall cedarscript-grammar
But received the following error message:
Collecting cedarscript-grammar   Using cached cedarscript_grammar-0.5.0-py3-none-any.whl.metadata (23 kB) Collecting tree-sitter~=0.21 (from cedarscript-grammar)   Using cached tree_sitter-0.23.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (9.8 kB) Using cached cedarscript_grammar-0.5.0-py3-none-any.whl (91 kB) Using cached tree_sitter-0.23.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (571 kB) Installing collected packages: tree-sitter, cedarscript-grammar   Attempting uninstall: tree-sitter     Found existing installation: tree-sitter 0.21.3     Uninstalling tree-sitter-0.21.3:       Successfully uninstalled tree-sitter-0.21.3   Attempting uninstall: cedarscript-grammar     Found existing installation: cedarscript-grammar 0.5.0     Uninstalling cedarscript-grammar-0.5.0:       Successfully uninstalled cedarscript-grammar-0.5.0 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. aider-chat 0.58.2.dev669+gae93ecdd requires tree-sitter==0.21.3, but you have tree-sitter 0.23.2 which is incompatible. Successfully installed cedarscript-grammar-0.5.0 tree-sitter-0.23.2
After that, running aider again produces the same error:
[find_cedar_commands] Script block count: 1 [cedarscript_grammar] Loading native CEDARScript parsing lib from /opt/miniconda3/envs/aider_cedarscript_env/lib/python3.12/site-packages/cedarscript_grammar/libtree-sitter-cedarscript.so Failed to load native library: /opt/miniconda3/envs/aider_cedarscript_env/lib/python3.12/site-packages/cedarscript_grammar/libtree-sitter-cedarscript.so: cannot open shared object file: No such file or directory
I am going to clear my conda cache and try again (you can see it's using cached packages, maybe corrupt?)
I did already get the same errors using venv so it's not conda specific. I will try with venv also using the latest recommended install command and report back - if none of those work I am stumped, I suspect Arch/Manjaro doing something - the libtree-sitter-cedarscript.so file is present in the environment binary directory just not being picked up. I use conda and venv all the time though and so far no issues with other packages installed via pip. AMD64 laptop. Up-to-date Manjaro installation.

After clearing conda, pip cache, re-installing everything using venv and conda I still get the same error:
libtree-sitter-cedarscript.so: cannot open shared object file: No such file or directory
Any suggestions welcome.

try to check the file size and output of file <so-file>

file /opt/miniconda3/envs/aider_cedarscript_env/lib/python3.12/site-packages/cedarscript_grammar/libtree-sitter-cedarscript.so
/opt/miniconda3/envs/aider_cedarscript_env/lib/python3.12/site-packages/cedarscript_grammar/libtree-sitter-cedarscript.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=167a842443c8a279691fd7c48f2f45956e346d4b, not stripped

OK so it seems I have the ARM64 version. How did this happen and how can I fix it? Any attempt to re-install ends up the same. Could I have done this myself by mis-configuring while compiling the source once?
First time this happened to me. I will look at it some more. At least I know what the problem is now.

OK I have tried various things - I can't get cedarscript-grammar to compile, some sort of npm problem (I don't use that much so no idea) but I did try to get pip to compile it for me using --no-binary=:all:, and a few other things like pip version, npm version... No luck.
Anyway it's a libtree-sitter-cedarscript.so problem so please close this issue if it's not relevant here.
The only thing I want to know is, does CEDARSCRIPT with Aider actually work on X86-64? I just wonder if it's a new mac specific program and that's why I can't get it to run.

I need to compile a shared lib for your architecture...
Or you could help me and compile it.
Can you please check out CEDARScript grammar (https://github.com/CEDARScript/cedarscript-grammar.git)
and then run
make build

This should create a shared lib file at src/cedarscript_grammar/libtree-sitter-cedarscript.so
Can you send this file to me please?
Thank you for your effort to solve this issue!

This should fix it.
Can you please try again with cedarscript-grammar 0.5.1 ?


Integrate with Google Analytics

We need to add analytics bindings to actions and button presses/page accesses so we can better understand what features are being used and focus on the most important features.
We also need Google Analytics to get general statistics such as unique users etc.
We'll monitor the new site under the Google Analytics property antalmanac-rewrite

[ ] Add privacy policy notification/checkbox banner to site. A good place for this would be in the right pane at the bottom. Dismissing this should save a boolean to localStorage so it doesn't popup if that variable is set true in there.

Track clicks on these actions below

[x] Left Pane - Kartik

[x] Click Screenshot button
[x] Click Custom Event button
[x] Click Clear button
[x] Click Undo button

[x] Class search tab - William

[x] View/Click "Map" tab in right pane
[x] View/Click "Added Classes" tab in right pane

[x] Top bar - Kartik

[x] Click "Settings"
[x] Click "Notifications"
[x] Toggle Dark Mode

[x] Class search after completing search - William

[x] Click "Past Enrollment" button
[x] Click instructor name
[x] Click section code

[x] Added classes tab - Monica

[x] Click copy schedule
[x] Click clear schedule
[x] Click on color to change course color
[x] Delete course

Any thoughts on this as the privacy policy notice? Also tagging @ChaseC99

Any thoughts on this as the privacy policy notice? Also tagging @ChaseC99

LGTM 👍🏼


Problems with "Quick Start with Docker" instructions

I am encountering several problems while going through the Quick Start with Docker instructions from the documentation. I've tried them with Docker Desktop on both Mac M1 and Windows machines and am not able to reproduce the results from the instructions.
Here are the issues I've encountered:

Dashboard is not accessible at localhost:8000 ("localhost didn’t send any data") when the container is running
Running the provided docker run command does result with a psql prompt, but includes an error message ("sudo: handle_sigchld_pty: waitpid: No child processes")
Running the example Embeddings command returns this error: ValueError: Loading Alibaba-NLP/gte-base-en-v1.5 requires you to execute the configuration file in that repo on your local machine. Make sure you have read the code there to avoid malicious use, then set the option trust_remote_code=True to remove this error.
Under "Training an XGBoost Model," the trained model has much worse metrics that what is shown in the instructions: {"f1": NaN, "precision": 0.1, "recall": NaN, "accuracy": 0.100222714, "mcc": NaN, "fit_time": 0.035050604, "score_time": 0.00171086}
And obviously the predictions from this model do not match what is shown in the instructions.

It would be helpful if the instructions were updated with corrections and/or clarifications. Perhaps there are missing steps that can be documented? Or maybe they are not aligned with the latest published docker image?

To fix the third issue:
SELECT pgml.embed(
    'Alibaba-NLP/gte-base-en-v1.5',
    'passage: PostgresML is so easy!', '{"trust_remote_code": true}'::JSONB
);

Related doc that I found since I had the same issue:
https://postgresml.org/docs/open-source/pgml/api/pgml.embed

Thanks @oliviernabuio, I had figured out the same on Sunday. But thanks for confirming, because I also noticed the embedding doesn't match the results in the documentation.

I'm going to close this issue and open new ones for each of the remaining issues. I think 4 & 5 are probably just the documentation needing to be updated. For the first issue with the dashboard, I think that could be an actual bug in the code or the container. When I docker exec into the container, the pgml-dashboard process has a status of defunct.


macOS: -c option does not exist for stat

It formats the output, so stat -c "%A" should format the permissions in a human readble way.

   -c  --format=FORMAT
          use  the  specified  FORMAT  instead of the default; output a newline after each use of
          FORMAT

   ...

   %A     permission bits and file type in human readable form

Fixed by using stat -f %Sp on macOS.


Conversion from CAHVOR Model to Photogrammetric Model

Add a code to get Photogrammetric Model from CAHVOR model.

Issue resolved in #7


integrate API Attribute backfiller & Unique String Aggregator to Core

Is your feature request related to a problem? Please describe.
While developing app functionality for nikean.org we had to write a 2 custom plugins. One to backfill API Namespace attributes (used when product requirements changed) and another to build lists of unique strings. These plugins were written quickly and are well past their use-by date.

Describe the solution you'd like
Lets move these to Violet Core, put the functionality behind a User Interface and have it maintained as part of the monolith codebase.
These plugins are installed and tested in the test suite, see the following releases that introduced the plugins:

Unique String aggregator: https://github.com/restarone/violet_rails/releases/tag/0.9.49
Create External API Connection that backfills attributes on API Namespace + API Resources  https://github.com/restarone/violet_rails/releases/tag/0.9.25

This UI does not change

Plugins tab

requirements:

make sure that it can hold any number of plugins (as a list)
be able to organize a potentially large number of plugins in an intuitive way

attribute backfiller requirements
let the user define the attribute and the default value:


PodSecurityPolicy: unable to admit pod: []:Deployment does not have minimum availability.

In what area(s)?
/area operator
/area docs
Ask your question here
Are there any docs on how to deploy the operator, dashboard, and applications into K8s when K8s is enforcing PodSecurity Policies?

Could you share more details about how to reproduce it?

This isn't a direct answer to your question, but PodSecurity policies are now deprecated in K8s and will be removed in 1.25, so I don't foresee this becoming a guidance in docs.
Also this is very much ties to the type and configuration of the policy being enforced, and so it's difficult to help without more information.


viewBox not supported

Does any plan for add viewBox props to AnimatedSvg component?

Let me look into this. Submit a PR if you want.

Let me look into this. Submit a PR if you want.

Sure, May I access the repository?

Let me look into this. Submit a PR if you want.

https://github.com/kostimarko/rn-content-loader/pull/7#issue-261554395

merged:2a98d3b


Android TV support?

Is it fully supported in Android TV?

I also want this to have full Android TV support.

Is it fully supported in Android TV?

Yes, and no. It'll boot and work mostly, but on (for instance) the Nvidia Shield the gamepad seems only partly supported. Pausing the video is a little awkward, as there is no button mapped to do so.
I too would love having (better) ATV support though! Mostly by for instance bringing up the menu when [D-pad DOWN], or pausing be pressing [A]. The app is also not recognised as an 'official' ATV capable app, so it's not addable to the regular home menu without 3rd party apps.
Loving it so far though! 💕


Allow passing env variables to LSP configuration

This PR adds the ability to pass environment variables to the language server via an env setting in the LSP config.
Motivation

I was trying to run a very non-standard Sorbet configuration in https://github.com/ruby/prism/pull/2561 and wanted to use the LSP server to help with fixing the type errors.
However, I needed to pass the BUNDLE_GEMFILE env variable to make bundle exec srb use the correct gemfile. I realized that there was no way to pass env variables to the language server process and decided to add support for them.
Test plan

See included automated tests.

@froydnj Not terribly urgent, but if this PR is good to go now, could we get it merged?

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_PlblZjjMIHBSqI
→ https://go/builds/bui_PlblGs4tWFGxg6
→ https://go/builds/bui_PlblUbWq7hFSt6


ISPN-6501 Create a ProbeHandler for JGroups

https://issues.jboss.org/browse/ISPN-6501

note tested in embedded mode only.

Integrated, thanks @pruivo :)


Add BlockList events for all network protocols

Add BlockList event for all protocols like Http, Ldap, ...

@syncpark Could you take a look at my PR review-web and let me know if any adjustment is needed, thanks


fix matching of current buffer inside of line with all buffers

Use word boundaries around current buffer name when try to match in buffer line
For example this commit fixes the issue that when you have two buffers open, foobar and bar, it highlights the correct buffer.
Before the problem was if you have the bar buffer open it highlights the bar of foobar.
:beers:

looks some some other regression was introduced, so i had to revert.

looks some some other regression was introduced, so i had to revert.


Updated script using "Az" module

There is some script that use new "az" module instead of "AzureRM" module?
I tried to replace all "AzureRM" module cmdlets by "Az" module cmdlets and got two errors:
Import-Module : The specified module 'Az.Profile' was not loaded because no valid module file was found in any module directory.
At #FILEPATH#\New-RunAsAccount.ps1:92 char:1

Import-Module Az.Profile

  + CategoryInfo          : ResourceUnavailable: (Az.Profile:String) [Import-Module], FileNotFoundException
  + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

And:
#FILEPATH#\New-RunAsAccount.ps1 : Please install the latest Azure PowerShell and retry. Relevant doc url :
https://docs.microsoft.com/powershell/azureps-cmdlets-docs/
At line:1 char:1

.\New-RunAsAccount.ps1 -ResourceGroup $RGAutomationName -AutomationAc ...

  + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
  + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,New-RunAsAccount.ps1

Has anyone faced this difficulty?

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

ID: 56e2500f-e1f5-bc87-6e5c-f41b59265049
Version Independent ID: d212be48-7d05-847d-3045-cea82e6ba603
Content: Manage Azure Automation Run As accounts
Content Source: articles/automation/manage-runas-account.md
Service: automation
Sub-service: shared-capabilities
GitHub Login: @bobbytreed
Microsoft Alias: robreed

Thanks for your comment. We are actively investigating and will get back to you shortly. Thanks for your patience.

@ralmeidads  apologies for the delayed response. If you haven't already, would recommend following these updated guidelines migrating existing scripts to Az -  detailed here.
will now close this request but please Don't hesitate to respond if you have any follow-up questions.
Cheers.


fix(js bug): add missing loan options js file

Fixes oah-notes 1050, JS bug on Loan Options subpages due to missing JS file in Gruntfile. See the live site for the error this fixes: http://www.consumerfinance.gov/owning-a-home/loan-options/conventional-loans/
Additions

adds missing js file to the build step in Gruntfile

Testing

check out locally and run grunt
navigate to http://localhost:7000/loan-options/FHA-loans/ and check for "Failed to load resource: the server responded with a status of 404 (NOT FOUND) for http://localhost:7000/static/js/loan-options-subpage.js?v1" error.
the error should be gone
there is a different JS error that is still being fixed that will occur on this page, " Cannot read property 'top' of undefined" please ignore :see_no_evil:

Review

@virginiacc

Looks good! :+1:


How DockerContainerStatus works?

Hi, thanks for the great app.
I'd like to know how DockerContainerStatus works: In my environment and config, that seems not work, even if there is a container with the name running.
I'm running minmon by sudo docker run -d -v ./minmon.toml:/etc/minmon.toml:ro --name minmon ghcr.io/flo-at/minmon:latest.
My config for DockerContainerStatus:
[[checks]]
interval = 60
name = "Docker containers"
type = "DockerContainerStatus"
containers = ["gollum"]

[[checks.alarms]]
name = "Warning"
cycles = 3
repeat_cycles = 100
action = "Webhook 3"
recover_cycles = 5
recover_action = "Webhook 3"
error_repeat_cycles = 200
error_action = "Log error"

[[actions]]
name = "Webhook 3"
type = "Webhook"
url = "https://discord.com/api/webhooks/foo"
body = """{"content": `{{check_name}}`: Alarm `{{alarm_name}}` for container `{{check_id}}` changed state to *{{state}}."}"""
headers = {"Content-Type" = "application/json"}

$ sudo docker ps -a
869484fff354   gollumwiki/gollum:v5.3.0       "/docker-run.sh"         10 days ago    Up 10 days             <IP_ADDRESS>:4567->4567/tcp, :::4567->4567/tcp                                                  gollum

Error message:
2023-07-27T21:12:18Z [INFO] Alarm 'Warning' from check 'Docker containers' will be triggered after 3 bad cycles and recover after 5 good cycles.
2023-07-27T21:12:18Z [INFO] Check 'Docker containers' will be triggered every 60 seconds.
2023-07-27T21:12:44Z [WARN] Check 'Docker containers' got no data for id 'gollum': Docker error: error trying to connect: No such file or directory (os error 2)
2023-07-27T21:12:44Z [ERROR] Alarm 'Warning', id 'gollum' from check 'Docker containers' got an error: Docker error: error trying to connect: No such file or directory (os error 2)
2023-07-27T21:12:44Z [WARN] Alarm 'Warning', id 'gollum' from check 'Docker containers' changing from good to error state.
2023-07-27T21:12:44Z [INFO] Action 'Log error' triggered for alarm 'Warning', id 'gollum' from check 'Docker containers'.
2023-07-27T21:12:44Z [ERROR] Docker containers check didn't have valid data for alarm 'Warning' and id 'gollum': Docker error: error trying to connect: No such file or directory (os error 2).

It seems this line Docker error: error trying to connect: No such file or directory (os error 2) is the cause of this error, but I don't get what that means in this case. Container named gollum is running as docker ps -a shows, but minmon cannot get that information, or do I miss something?
Thanks in advance.

Thanks for the feedback!
Is your dockerd running? And is the dockerd socket at the default path? I'll double check it in a few days as soon as I have some spare time.

Yes, docker version works properly.

Client: Docker Engine - Community
 Version:           24.0.4
 API version:       1.43
 Go version:        go1.20.5
 Git commit:        3713ee1
 Built:             Fri Jul  7 14:51:00 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.4
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.5
  Git commit:       4ffc614
  Built:            Fri Jul  7 14:51:00 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

# systemctl status docker
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Mon 2023-07-17 09:19:29 JST; 1 week 4 days ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 4043 (dockerd)
      Tasks: 142
     Memory: 67.0M
        CPU: 11min 5.424s

Yes, I've not messed with docker.conf, and there is /var/run/docker.sock.

I didn't realize you're running MinMon inside a docker container until now. The problem is most likely this:
Inside the docker container that is running MinMon, the docker socket (from the host) is not available.
You can mount it if you add the -v /var/run/docker.sock:/var/run/docker.sock argument. MinMon can than talk to the host docker service using this socket and check the containers.
Let me know if this solves the problem! I'll add a note in the documentation about this.


Host/ComputerSystem API support

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature
What happened:
OpenSDS provides a platform for Data Management in on-premise as well as multi-cloud environment. Data Management includes identifying the resource. The node or Host is one of the key resources which manages as well as can facilitate the data in the data path.
OpenSDS should be aware of the Hosts it is managing. That means OpenSDS should be able to discover the Host and its associated resources. These information can be used for Host based replication, Host resource provisioning etc.
In addition, Issue #1023 also tell us it is essential to add host resource management in hotpot.
What you expected to happen:

Add host management feature.
Update attachment API based on new Host API.
Host management in Dashboard: https://github.com/opensds/opensds-dashboard/issues/205

Anything else we need to know?:
Tentative design at: Click here
Environment:

Hotpot(release/branch) version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

this issue is ready to close


LD_PRELOAD in electron 13 wrapper breaks unwrapped commands called by obsidian.

Describe the bug
Obsidian is unable to run (non-nixpkgs) git commands, due to $LD_PRELOAD being prefixed with libXScrnSaver.
Steps To Reproduce
Steps to reproduce the behavior:

Have non-nixpkgs git
open obsidian from nixpkgs
Setup Obsidian Git in obsidian
Run the Obsidian Git: Backup Vault command

Expected behavior
Git syncing properly
Actual behavior
git: failed on initialization
Additional context
$ nix-shell -p obsidian

[nix-shell:~]$ head `which obsidian`
#! /nix/store/bm7jr70d9ghn5cczb3q0w90apsm05p54-bash-5.1-p8/bin/bash -e
exec "/nix/store/xcrfxl4cb8s0q0w3c5qanym06vdpahw1-electron-13.6.9/bin/electron"  /nix/store/g3hg2i1m81rf68xpansw9jqpg7yk7wkr-obsidian-0.12.19/share/obsidian/app.asar "$@"

[nix-shell:~]$ head /nix/store/xcrfxl4cb8s0q0w3c5qanym06vdpahw1-electron-13.6.9/bin/electron
#! /nix/store/bm7jr70d9ghn5cczb3q0w90apsm05p54-bash-5.1-p8/bin/bash -e
export LD_PRELOAD='/nix/store/2nldwldgaiwd0zwph8sj13xdiqysdxgb-libXScrnSaver-1.2.3/lib/libXss.so.1'${LD_PRELOAD:+':'}$LD_PRELOAD
export GIO_EXTRA_MODULES='/nix/store/wsc48b6izbpm0v70wv9dryrnb0776pq1-dconf-0.40.0-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
export GIO_EXTRA_MODULES='/nix/store/wsc48b6izbpm0v70wv9dryrnb0776pq1-dconf-0.40.0-lib/lib/gio/modules'${GIO_EXTRA_MODULES:+':'}$GIO_EXTRA_MODULES
export GDK_PIXBUF_MODULE_FILE='/nix/store/nlpa9gavw5zszfyp50krca2iba7ymhvn-librsvg-2.52.4/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache'
export XDG_DATA_DIRS='/nix/store/z2phd72675fma3nz1l4jzpignf4zycvd-gtk+3-3.24.30/share/gsettings-schemas/gtk+3-3.24.30:/nix/store/vsf6wf9g6glsdw3mkbyd0q5m1gmvcfb4-gsettings-desktop-schemas-41.0/share/gsettings-schemas/gsettings-desktop-schemas-41.0'${XDG_DATA_DIRS:+':'}$XDG_DATA_DIRS
exec -a "$0" "/nix/store/xcrfxl4cb8s0q0w3c5qanym06vdpahw1-electron-13.6.9/lib/electron/.electron-wrapped"  "$@"

[nix-shell:~]$ which git
/usr/bin/git

[nix-shell:~]$ echo $LD_PRELOAD

[nix-shell:~]$ export LD_PRELOAD='/nix/store/2nldwldgaiwd0zwph8sj13xdiqysdxgb-libXScrnSaver-1.2.3/lib/libXss.so.1'${LD_PRELOAD:+':'}$LD_PRELOAD

[nix-shell:~]$ git
git: symbol lookup error: /nix/store/65hafbsx91127farbmyyv4r5ifgjdg43-glibc-2.33-117/lib/libdl.so.2: undefined symbol: _dl_catch_error_ptr, version GLIBC_PRIVATE

Notify maintainers

@ConradMearns @zaninime @travisbhartwell @manveru @prusnak
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.25-1-MANJARO, Manjaro Linux, noversion`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.6.1`
 - channels(pbsds): `"nixpkgs-21.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/pbsds/channels/nixpkgs`

Why don't you use git from nixpkgs (e.g. nix-shell -p obsidian git)?

That does work, although I'd prefer not to install git with nix-env on manjaro. I have other workaround that i use, i simply wanted to report how libXss.so seem to break subcommands.

Just updated, and this also affects electron 16

We could consider prepending git to PATH in the derivation (the start script in the output).

We could consider prepending git to PATH in the derivation (the start script in the output).

@pbsds can you guesstimate how many percent of obsidian users have obsidian-git plugin installed?

Of all obsidian users: few.
Of obsidian∩nixpkgs users: maybe 20%?

Possibly related: #137871

@pbsds can you please check whether the fix in https://github.com/NixOS/nixpkgs/pull/172961 fixes this issue for you?

Seems to work!


install.sh detects the existence of OLM in a wrong namespace

Bug Report

What did you do?
Using install.sh to install OLM, I see the script always tries to deploy OLM even if that has been deployed on the target cluster already.
What did you expect to see?
The install.sh script should not always deploy OLM even it has already been deployed.
What did you see instead? Under which circumstances?
The current install.sh has a way to check and exit if OLM has already been installed. However, the namespace it uses, openshift-operator-lifecycle-manager, is not the one it is defined in a variable called namespace, where the value is olm.
The install.sh script should use the right namespace to check the existence of OLM deployment.
Environment

operator-lifecycle-manager version:

0.18.3

Kubernetes version information:

v1.19.1, but should impact all versions.

Kubernetes cluster kind:

v0.9.0, but should impact all versions.
Possible Solution
See above.

If needed I can submit a PR since it seems to be a simple fix.

@morningspace That particular line is actually a fail-safe to make sure that users are not trying to install OLM on an OpenShift cluster, which comes with OLM already installed in the openshift-operator-lifecycle-manager namespace.
However, I think what you're actually asking for is a check that prevents install.sh from continuing if it detects an existing OLM install anywhere in the target cluster?

@joelanford Aha I see, thanks for the clarification, and yes, that is what I am asking for, more accurately: prevents install.sh from continuing if it detects an existing OLM installed in the namespace where install.sh is going to install OLM. So, if I run install.sh for the second time against the same cluster, it exit immediately since OLM has already been installed in the target namespace. Does it make sense?

This is exactly what I mean. And, I assume both olm and openshift-operator-lifecycle-manager (per https://github.com/operator-framework/operator-lifecycle-manager/issues/2327#issuecomment-899476144) need to be covered.

Seems mostly reasonable to me. FWIW, I think operator-sdk olm install checks to make sure that none of the objects in the install manifests exist.
But checking for olm namespace is better than nothing and probably catches 90+% of what folks want.

Yeah, that sounds reasonable to me - @morningspace would you be willing to submit a PR that checks for the olm namespace in the install.sh bash script?

sure @timflannagan, the PR is ready for review :-)

#2334 just merged :tada:


Unable to Install or Save poshy-wrap-vscode from PSGallery

Expected Behavior
Should be able to install or save module from PSGallery
Current Behavior
Unable to save or install module from PSGallery
System.Exception: Unable to save the module 'poshy-wrap-vscode'

Save-Module -name poshy-wrap-vscode -Path . -Repository PSGallery
WARNING: Package 'poshy-wrap-vscode' failed to be installed because: The file 'C:\Users\username\AppData\Local\Temp\50fex4uo\[Content_Types].xml' already exists.
WARNING: Package 'poshy-wrap-vscode' failed to install.

Steps to Reproduce

Attempt to Save-Module from PSGallery
Attempt to Install-Module from PSGallery

Context (Environment)
$PSVersionTable

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

Fixed in https://github.com/pwshrc/poshy-wrap-vscode/releases/tag/v0.2.9. Thanks for reporting this!


Consider removing the "Docker image" option

code state: d447c22d3bf175dea68f0cf917c53f743d9efe1b

(About option b above):

(About option c above):

(About making software actually executable):

Just to clarify this a bit more, authors can choose to package their software in various ways, some more robust than others. If I understand it correctly, the selling point of Docker, Podman, AppImage, Flatpak, and Snapcraft is that they bundle all OS dependencies with the author's software, making it more reproducible and more robust.

The first answer seems like something no one would ever choose. "the software is available as is. No attempt is made to make the software easily executed." seems like its a more realistic expression of what happens.
The second answer is good. Or good enough.
In my opinion, the third answer goes too far. I'm not comfortable dictating a specific technical approach or technology as more FAIR. I reiterate what I said back in the google doc. I think we must stop at the second answer.

Updated as per your suggestions


Represent route on UI

For representing details of the route, datatables should be used: https://datatables.net
For displaying this Information there is the interface /service/data/

ui represented by data tables added


Pagination for tables

As a user I want not to see all 1000 rows in the table.
We need to spread them into pages.
For Users, Roles,Tokens, Clients, User Roles, Client Types, Approvals

Wait for fix in issue 611.
This issue is closed


clightning: 23.02.2 -> 23.05

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/ElementsProject/lightning/releases.
meta.description for clightning is: A Bitcoin Lightning Network implementation in C
meta.homepage for clightning is: https://github.com/ElementsProject/lightning
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.05 with grep in /nix/store/apxky7p24ixvmcxap3dq5ml3ksbv1jip-clightning-23.05
found 23.05 in filename of file in /nix/store/apxky7p24ixvmcxap3dq5ml3ksbv1jip-clightning-23.05

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
clightning

Instructions to test this update (click to expand)

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

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

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

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

1 package built:

clightning

Maintainer pings
cc @jb55 @prusnak for testing.

@GrahamcOfBorg build clightning