Consider using ts-semantic-testing

I've just published an early version prototype of an idea to help with writing tests for these kinds of projects, ts-semantic-testing. It's still very early days and potentially buggy and all subject to change, but I thought you might find it interesting to have a look at.

TypeScript: turn run-time errors into compilation errors

ts-semantic-testing: turn compilation errors back into run-time errors

😅
Honestly, I love this -- it's heart-warming this experiment to do a type lib is already spawning tooling specific to this niche. I'll try it out.

Have fun, feel free to request things or contribute or whatever if you'd like.
I've actually been thinking I may completely change around the API though, to something roughly like this. Basically break it away from transforming the full test files and tests, and just provide a single block that is transformed and makes any semantic errors available for assertions, in a completely test framework independent way.
it("uses the new rough API idea", () => {
    tsst(() => {
        // Semantic errors within here are returned as strings
        // Only the contents of tsst are transformed
        type A = B;
    }).expect.toNotFindType("B");
});

So feel free to play around with it, and use it if it seems useful in its current state, but beware this is all very prototype right now and will change drastically.

Oh, and while it's designed for this niche, I do wonder if semantic tests may sometimes be useful in more general contexts. The organisation that comes with a testing framework may be a nicer experience than just looking out for compile errors in some situations.

Features looked for to test types (also see https://github.com/sanctuary-js/sanctuary/issues/254#issuecomment-318912461):

testing things type-check: originally filled by TypeScript
testing for expected errors: tested within TS by its harness, outside of it originally by dts-lint
protecting against any inference: tested within TS by its harness, outside of it originally filled by typings-checker
getting version control friendly (= no line numbers) error logs for libs that still failed expectations: my typings-checker fork (used for Ramda typings)
combined testing of types and run-time results: dts-jest (used in impending PR to Ramda typings)
turning type errors into run-time errors to make named assertions: ts-semantic-testing

Seems to me that for this use-case you already had the right feature-set in mind.

I do wonder if semantic tests may sometimes be useful in more general contexts. The organisation that comes with a testing framework may be a nicer experience than just looking out for compile errors in some situations.

I'd be curious about its potential as well. Then again, normally people make tests to prevent regressions from sneaking in, whereas it's harder for compilation errors to sneak in without noticing upon compilation. In that sense, use-cases elsewhere might be more limited.
On tsst, so current API:
it("works with the number 0", () => {
  type A = ZeroOneToBoolean<0>;
});

What I had now in my attempt to test without names: the<number, 123>();
Imagined way the syntax could collapse:
it("is a number", the<number, 123>);

... Which would fail since generics for functions could only be provided upon calling them. They can be provided for types, but we want an expression-level function here. I guess one could be like
let x = null!; // short expression-level `never`, can be cast to anything
type TheF<T, V extends T> = () => V; // type-testing function type to lift to expression level
// options to invoke without calling function:
x as TheF<number, 123>;
<TheF<number, 123>>x;
// imagined test:
it("is a number", <TheF<
  number,
  123
>>x);

More of a thought experiment than pretty syntax. Also fails to yield a function expression on type error though which I suppose screws it up.
Do you have an example project you've actually already used it on by the way?

This project is currently horrendously untested because I'm not sure what the best way to test this is.

Put your example snippet in some sub-folder 'repository' and have a script calling it on that folder? Maybe have your CLI propagate the status code of the testing thing so you'd know where the testing thing reported errors? You could e.g. have one test project like that that should pass, another that should result in some error so as to check whether it'd correctly report success/failure based on your transformed types, I dunno.

issues with line-numbers

Hm. If the it blocks already describe what failed, then a work-around may be to limit it to one type per block or something.
I suppose if you could put your own example project for this up there it might serve simultaneously as both documentation on usage as well as a basis for testing 😅, right now running tsst doesn't seem to have it tell much as to what it's doing (is it outputting transformed files somewhere?), which is a bit confusing.

I'll work on getting a proper example out soon sure, that sounds good. And currently tsst is (theoretically, it was a 10 minute job that at least works locally for me) just running the compiler against your tsconfig.json in pretty much the same way just running tsc would, but only emitting files where the source file matches the glob.
It's literally just this:
    const projectPath = project || "./";
    const configPath = ts.findConfigFile(projectPath, ts.sys.fileExists);
    const basePath = path.resolve(path.dirname(configPath)); /*?*/
    const configReadResult = ts.readConfigFile(configPath, ts.sys.readFile);

    if (configReadResult.error) throw new Error("Error reading tsconfig.json");

    const config = ts.parseJsonConfigFileContent(configReadResult.config, ts.sys, basePath);
    const program = ts.createProgram(config.fileNames, config.options);
    const transformer = makeTransformer(program);

    program.getSourceFiles()
        .filter(file => minimatch(file.fileName, glob))
        .forEach(file => program.emit(file, undefined, undefined, undefined, {
            before: [transformer]
        }));

Thanks! That's illuminating, let me try for a sec then.

This stuff is great, love to see progress in this space.

Oh, I installed a local version figuring globals are an anti-pattern with version control, then erroneously tried running index.js instead of build.js, so that explains why mine silently terminated.

Oops, sorry. Yeah, I'm working on the example now, it's a little tricky to work out how to nicely integrate with an existing test framework because you have to do the transformations before the tests... I think the version I put up will be working but a mess, will have to find/build a better way at some point.
Just to be clear about running the build, tsst is a bin in the package. So if you've installed the package globally you should just be able to run tsst on the command line, or add this in the package.json and npm test.
"scripts": {
    "test": "tsst"
}

I've clearly explained that awfully, sorry. I'm prototyping/iterating significantly faster than I'm documenting.

Sorry, I ended up mostly having to deal with some other boring stuff today, didn't get as much time to work on this as I would have liked. https://github.com/TheOtherSamP/tsst-example-project is now a thing, I think it works.
I've been having a slight issue installing it, I've been intermittently getting a weird
npm ERR! enoent ENOENT: no such file or directory, rename 'D:\tsst-example-project-master\node_modules\.staging\tsst-36171f51\node_modules\@types\minimatch' -> 'D:\tsst-example-project-master\node_modules\.staging\@types\minimatch-b98dca64'
error when npm installing in the project directory. I think this is probably local to my system (I've had a few other problems with NPM, I need to clean that up) but if this happens to you, I've managed to get around it by manually npm install tsst, then npm install. No idea why.

Oh, and I completely changed the syntax around, surprise!

Hm.

I also get that npm issue. Thanks for the workaround.
npm test then yields /usr/bin/env: ‘node\r’: No such file or directory for me (Ubuntu) due to the bin file using Windows breaklines (CRLF) over Unix ones (LF). For me VSCode shows an option to fix that in the bottom-left corner, allowing me to get to the next stop. For a long-term solution, it appears that Git automatically fixes CRLF to LF, while npm does not. I wonder if you could publish to npm again after setting your local editor to use Unix breaklines?
got some Determining test suites to run...(node:5680) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): SyntaxError: Invalid regular expression: /js-tests\(.+)\.test\.js$/: Unmatched ')' apparently due to old global install, fixed when using local install. this is why I prefer local installs, less version mismatches. :b
trying node_modules/.bin/tsst -b tests/*.test.ts -d ./tests terminates silently. minimatch appears to reject the global, file.filename /path/to/tsst-example-project/tests/operators.test.ts, glob somehow tests/operators.test.ts, minimatch then yielding false.
not sure if it can make that js-tests dir for you, probably blocked by the above

Huh, I'm on Windows and don't have easy quick access to a Ubuntu environment for testing right now.
I should probably mention that I'm more of a .Net dev historically, I may be making silly mistakes here, I'm learning as I go, sorry.

not sure if it can make that js-tests dir for you, probably blocked by the above

Works for me.

I also get that npm issue. Thanks for the workaround.

Strange. I'll clear everything out and see if I can work out what's going on there. I don't think I've done anything particularly weird with NPM here, so not sure what's up with that.

I wonder if you could publish to npm again after setting your local editor to use Unix breaklines?

On it now, sorry. I should have had that set already, my bad.

trying node_modules/.bin/tsst -b tests/*.test.ts -d ./tests terminates silently.

I'll throw some logging in there quickly. I'm not immediately sure what's going on with that error either. Could that be a Unix thing with path handling somewhere? Apart from the NPM thing, just copying down the folder from github and running locally just works for me.
Aaand this already became a support job. 😂

Sorry, seems quotes matter for me, my bad.
node_modules/.bin/tsst -b tests/*.test.ts -d ./tests
glob: 'tests/operators.test.ts'

node_modules/.bin/tsst -b "tests/*.test.ts" -d ./tests
glob: 'tests/*.test.ts'

So file name /path/to/tsst-example-project/tests/operators.test.ts, glob tests/*.test.ts, minimatch still reports false. Hm.

My bad, swapping tests back to ** fixes the check.

Hmm, but I think that should have worked. I just threw the standard minimatch in there and assumed it would just work, but that does seem to be an issue, maybe I need to mess with options for it or something. I'm actually seeing the same thing here when I set that to tests/*.test.ts.
Nothing's ever simple. 😂

Transpilation now works fine. Running jest still throws the regex error but that might be some version thing. Checking.

No, that's actually just a buggy regex I wrote. Your error is write, the confusing thing is that it works for me.

Thanks, yeah, just saw it. Made a PR, probably at the same time as you fixing it haha.

Uh, actually, that 'fix' is wrong. Would "js-tests\/(.+)\\.test\\.js$" work on Windows? I'm unsure due to the slash. Works for me.

I've been awake for about 30 hours and drank too many coffees, try not to judge me too harshly for how much of a mess I just made of the commit history. No, blame me, that's fair. 😂

Actually I'm going to disappear and sleep now before I accidentally destroy this whole project.

Get some rest, you deserve it 😃, I'll try to see what I can do to incorporate this over here! Heck, I'm pretty sure @gcanti should be interested too!

Have fun, thanks for all the help. If I don't spend the whole day battling the weird NPM issue I think I'm going to try to get a basic expectation/assertion system in it tomorrow. And fix the millions of bugs I've probably sleepily put into it today.

Yeah, I'll try a bit as well, expect another PR or two.

Note that the setup of tsst-example-project allows one to have tests import types, one cannot import non-type TS （like the) with it.
I tried to chop the .d off the operators.d.ts file name, which makes the behavior of tsst magically change -- suddenly it dumps the resulting JS files not in js-tests, but in js-tests/tests.
Moreover though, as the regular TS compilation process is skipped, meaning it will transpile the import statements, which will then no longer have anything to import from.
So um yeah, not much success making things terser at least.

It just occurred to me one part that might not become 'like JS' is types bugged to the extent of failing to terminate.
As the actual type evaluations don't actually occur separately at run-time, a non-terminating type would just make tsst hang.
This isn't actually a regression from what things have been like, just a point hard to improve on.

It's working okay; currently trying this out with a few different testing frameworks. My priority there is pretty much stability of output for the purpose of diffing the output with version control:

jest: kept randomizing order even with --runInBand, ugh. no-go.
jasmine: shows stack traces even if just throwing a string (failed to disable), numbers its errors (haven't found mention of how to disable)
mocha: shows stack traces even if just throwing a string (failed to disable), numbers its errors (haven't found mention of how to disable)
karma: didn't get it to run yet

Finished refactoring everything. Tests are more verbose this way but the superior error reporting was totally worth it.
Made some commits to tsst though I've mostly just been editing the same branch rather than separating everything, so excuse my git hygiene. If you don't like part of it, feel free to kick it out. :P

It just occurred to me the issue of non-terminating types appears potentially solvable.
If the types are transformed in isolation, then perhaps a wrapping the evaluation step in a promise/observable with time-out  could serve to cancel the operation before it hits a stack overflow.
Being able to incorporate potentially non-terminating types instead of having to comment them might go a long way toward being able to easily test against different TS versions such as to pinpoint potential regressions.

Sorry, I haven't been able to get to much of this so far today. Could you explain what you mean by "non-terminating types"? I don't think I've ever come across this phenomenon. It's possible to write types that just hang the compiler?

It's possible to write types that just hang the compiler?

Yeah. It's a small difference in a sense. Iterating over tuples types for one involves recursion -- you continue until hitting a condition (finishing to iterate over the whole thing). If a TS glitch breaks the condition, it may never terminate, causing the compiler to blow up with a stack overflow.
Still affected by this are array's ListFrom, comp's Max and Min, and number's DivFloor and Modulo. This also affects tests for array's ConcatNumObjs / IncIndexNumbObj and list's ConcatLists, IncIndex and Prepend. Until yesterday there were actually a dozen more. As it stands there is no automated way to judge whether a type terminates.

Preview of what I'm sketching out and aiming for with the API:
tsst<NumBoolToBool<"0">>().is<false>();
tsst<number>().accepts<5>();
tsst<AFakeType>().fails().withMissingName("A");
tsst<NumBoolToBool<{}>>.fails.withConstraintMismatch(/*constraint position*/ 1);

The larger block syntax will probably remain as well, it's more versatile but more verbose. These assertions are relatively tricky to add as some of them (the positive ones, is for example) will need to be done in the transformation phase rather than at runtime. I want to do it this way for the superior versatility and better error messages though.

Yeah. It's a small difference in a sense. Iterating over tuples types for one involves recursion

Huh, I haven't actually looked at type iteration yet so I haven't really come across that. If the compiler blows up I think we're stuck, the best I could do is catch that from the build script. The transformer isn't "evaluating" the types, it's just reading out the same "diagnostics" from the language service that the IDE is. This will behave in pretty much the same way VSCode behaves for those types, I imagine.

I'd suggest not to go full out in that direction just yet

Yeah, I basically agree. I'm more designing around having those be possible. I'd also have a generic method on .fails() that accepts a message string or regex to match against. Things like withMissingName() would just be shortcuts for a few of the common regexes. Once that infrastructure is in place more could then be added per demand. Note that .fails() already asserts a failure, the others just add optional extra specificity.

let type = await Observable.defer(getType).timeout(200, 'Timeout').toPromise()

I don't really understand where this would go in the process, but I'll have to wait until I've looked over the iteration stuff to get an understanding of that. Do you have a good little reproduction for that somewhere?

tsst api

Fair enough.
If you're interested in TS errors, you may wanna check their list; if you wanted to make something generic in that direction you might just consider generating it from that. That could probably make for some function catchError(code, ...args), such that to catch e.g. this random excessive stack error you could then be like withExcessiveStack = (s1?: string | RegExp | null, s2?: string | RegExp | null) => catchError(2321, s1, s2) or... something.

Oh, that's really useful, I probably could auto generate from that list, and maybe partially use the codes too as they're probably more reliable than the messages. Good find/thought, thanks.

recursion

Take Length for one. It starts at 0, checks if your tuple has that, until it doesn't. At that point it knows your tuple's length. Sounds silly compared to JS where you can just check length, but you can't use that for types. Or well, you'd just get number.
As for still failing ones, well, the currently commented types I mentioned here. Uncomment any of them and tsc / tsst will blow up.

I don't really understand where this would go in the process

That getType should stand for our () => program.emit(file, undefined, undefined, undefined, { before: [transformer] }).

with currying, hopefully it could just become withExcessiveStack = catchError(2321). heck, make that a R.map (using Ramda) over { withExcessiveStack: 2321 } // add more then convert. look mom, no custom code!

I pushed a commit based on the timeout idea, which slightly improves on the situation for non-terminating types by skipping files on timeout, rather than waiting for a minute then having tsst itself blow up with a stack overflow. If only they'd been evaluated on a case-by-case basis perhaps this could just yield a failing test for that type rather than having the entire file not pass the transform. It's a step forward at least I guess.

I managed to use a sed regex to remove error numbers from mocha output, so test output is version control friendly now. Time to do some version testing! 😃

By the way, I can't install tsst from github as it errors with ENOENT: no such file or directory, chmod '/blah/node_modules/tsst/dist/build.js' -- the dist directory it's trying to access has not been generated yet if installing from git, so tsc may need to be run before it tries that. It seems if run through install scripts it's run from the parent project's path, so the command may need an explicitly specified relative path.
It seems the preinstall script triggers before that error, so I tried to have that run tsc. That seems too early though -- at that point it just errors there is no such directory yet. However, the other scripts seem not to trigger until after it's already errored about not seeing the build.js though, so I'm having trouble figuring it out.
One other issue: I'd like tsst to respect the TS version of the parent project, so I hope using peerDependencies (with version * for TS) could fix that. Dunno if this issue might be because I'm using an npm link-ed tsst though.

Sorry I disappeared for a bit, had a very busy period but I've got a bit of time to put towards this again now.

By the way, I can't install tsst from github

Good point, I hadn't considered installing direct from github when I set that up, I'll take a look at tidying that up and getting it working.

I'd like tsst to respect the TS version of the parent project

Yeah, this one is a little tricky. In principle I agree, but the problem lies in the fact that the compiler API isn't very stable yet. I might be able to get it working with a tested range of peerDependencies versions somehow but ultimately, until the API stabilises, versions of tsst will be tied to versions of typescript.
Speaking of compiler versions, the full features of the error assertion API (mainly the .is<T>() method) are waiting on #9879. That's an old proposal that  even has a PR at #9943 but hasn't seen any movement for a while. That's essential for doing transform-time type assertions or checks. I'll be putting in a petition to get that revived at some point. Until then, we'll just have to fall back on the current style of The assertion, though it's far from ideal.

Thanks for the links. In case they forgot the thread I added my own nag there fwiw. :)
Wish I knew why PRs seem to just get stuck in there!

Hey, I'm sorry I completely dropped out here. I'm moving house in a few days, very busy at the moment. I've got plans and a new prototype for a new version that I'll hopefully be releasing... soon. It's pretty much going to be a ground-up re-write.
As a basic outline of what I'm working towards, I'm actually stepping back and simplifying. I'm taking out the expectation/testing code, and having tsst<T>() return an object with information about the type (and any errors) that can then be used within any existing testing/expectation framework.
I also have a (prototype) version of the tsst<T>().is<string>() method working. The implementation is entirely ridiculous and inefficient, but it functions. Actually I'm just going to explain it now because it's amusing how terrible it is.

The main transformer starts by making a sub-transformer.
The sub-transformer transforms a copy of each sourcefile, turning each call to .is<T>() into an anonymous function mimicking the the<string, "hello world">() system.
The result of this transformation is then written out by the printer into a string.
An entirely new program is created from these transformed files, re-parsing and checking everything.
The transformed files are then scanned for any diagnostics within our created the<string, "hello world">() functions, and those are matched up with the original is<T>() calls.
The original file is then transformed, using the diagnostics from 5 to pass or fail the is<T>() calls.
I either laugh or cry, I haven't decided yet.

No prob :), most of my currents efforts have been to fix typical by fixing TS anyways.
Pretty awesome you managed to get the compact API working! Looks like there's some progress on TS exposing the checking functions, but it's not in yet. But yeah, that may help simplify further on your end.
That said, looks like your version may only mean +100~200% more processing, which considering the small size of type libs like this is pretty much fine!

 A proper API would make things much smoother though. I do see this being potentially useful in more general libs though. Anything that's exposed as an API I can see myself maybe wanting to assert the type of in tests sometimes, that could be particularly nice with Jest's snapshot testing for spotting API regressions.
I'm also looking into providing a Jest transformer to allow this to work smoothly with TS source, but not sure of feasibility yet.

As a target, I'd also like to be able to compare an object instance against an interface to assert that return values really do conform to their types, but I think that's probably fairly far off still for now.

By "fairly far off", I may well mean impossible. Things like fully checking the return types of functions will likely never be possible. That idea is still in the early stages of wouldn't-it-be-nice-if, don't expect it to become reality.

Although, if you fancy putting in a PR that solves the halting problem, I'll get right on that.

Return types feels hard, yeah -- if it's based on generics things quickly get hard to track in a generic way. I mean, try that for Ramda's path function. There's like nothing useful you can say about its return type in a general sense really.
The halting issue... so so far I got to have it crash only a single file rather than the whole script, which helped. A better solution... probably involves parsing the whole project without type checking, then separately checking the types in those tsst nodes?
Hopefully something like this to further quarantine the halt to the test level, rather than the file level... It sounds like that means there would no longer be file-wide type checks as before though, which... sounds... kind of breaking / different.

Oh, I'd completely forgotten about that halting issue, hah. I was actually just trying to make a bad joke about the impossibility of determining the return type of an arbitrary function because of the halting-problem in the comp.sci sense, but I do need to look into that TS problem too.
Yeah, we definitely need to type-check the whole thing, otherwise the tests are pretty much completely pointless - they'd only be able to check types defined within themselves. I think ultimately, other than crashing gracefully, dealing with that issue is out of scope. I see that as a TS crash that's on them to fix. Best case I might be able to detect it and suggest what's happened in the error message.
In terms of the comparing against interfaces idea I suggested, my current thinking is that it's probably theoretically possible with most things apart from functions, because we can't test what happens for every possible parameter or state. The best idea I have right now is somehow convert arbitrary objects into a form the compiler understands (maybe impossible) and pass them in and do checking by hacks similar to how I'm currently doing is<T>().  Realistically this is likely unachievable.

I still haven't looked into it, so this may not make sense, but I'd assume the best way for TS to solve the problem would be to fail as a type error if it detects that it can't resolve the type. It would be a weird (but hopefully rare) error for developers, but it's probably the best option unless the problem can be eliminated.

Yeah, we definitely need to type-check the whole thing, otherwise the tests are pretty much completely pointless - they'd only be able to check types defined within themselves. I think ultimately, other than crashing gracefully, dealing with that issue is out of scope. I see that as a TS crash that's on them to fix.

Yeah. I thought they already had some similar errors for types that seemed 'too' recursive. It definitely isn't practical to resolve from our end here.

I'd like to be able to compare an object instance against an interface to assert that return values really do conform to their types

So bridging run-time (JS) and compile-time (type) testing huh?
Sounds like we'd have a Jest test involving some return value, which we'd then parse to infer its type, and add a tsst 'type-level' test checking if that inferred type matches the interface the function returns. Sounds... doable?

By the way, short-term gains might be to just npm publish a current (pre-refactor) version, optionally git install proof so you wouldn't need to npm publish every single commit to make them consumable. :)

My intuition is that it's doable for the simple cases, but impossible in the general case. Which arguably makes it useless.

which we'd then parse to infer its type

Doing this for a JSON-serialisable object is easy. Doing this for any object is hard. Anything that can't be represented by an object literal, I think we're going to hit a roadblock with.
If we can't reliably assess any object that we feed into the test then the test is pretty much useless.
We may be able to make it work for any object, but only for a subset of all possible interfaces. At that point it's still a hassle, of limited use, and probably not worth it.

By the way, short-term gains might be to just npm publish a current (pre-refactor) version, optionally git install proof so you wouldn't need to npm publish every single commit to make them consumable. :)

Yeah, I'm not actually even at the machine right now so I can't do this instantly, but I'll set myself the goal of getting a version up within 24 hours. Don't be surprised if I fail that goal though.

Although I'm not 100% sure I can't take an arbitrary object and reconstruct a TS compiler Type object piece-by-piece. That's getting pretty insane, but it might be theoretically possible. We'd still never be able to fully check return types or anything that wasn't deterministic.

Chances of the TS compiler actually exposing everything I'd need to do that at the moment are very low, too.

Doing this for any object is hard.

Isn't TS's raison d'être to gradually get to this point? Might be worth it to try and see how far off it ends up.
I might be missing what you're getting at -- would you have examples of hard cases?

Although I'm not 100% sure I can't take an arbitrary object and reconstruct a TS compiler Type object piece-by-piece. That's getting pretty insane, but it might be theoretically possible.

I suppose you did have the step of parsing a string into a node, if for a whole file?
Can't contain variables though or it'd no longer have meaning if parsed on its own.
Getting the type is createTypeChecker -> getTypeOfNode.

parsing a string into a node

Yes, this is definitely possible, I'm doing it now. Admittedly my current way of doing it is not ideal for units smaller than files (I create a SourceFile from string) but while a little silly and inefficient, it's perfectly possible to just do that and then extract the node. If you want full type checking in it, I think you have to do a weird round-about thing where you load it into the program as a fake file though. Again, I'm doing this now and it works, but it's ugly.
Simple example of a hard object:
const hardObject = {};
hardObject.self = hardObject;

If we just have variable hardObject and no knowledge of how it was created, there's no (easy) way to convert this into a string that the parser...
*thought happens*
Oh, okay, actually maybe there is.
For some reason I was thinking in terms of converting the object into an object literal in string form (so basically JSON but with basic function signatures) and giving that to the compiler, but actually it may well be possible to take a runtime object and produce a typescript code for an interface of that object.
So the hardObject above would just be:
interface $$tsstGeneratedInterface1OrWhatever {
    self: $$tsstGeneratedInterface1OrWhatever;
}

Maybe this is what you were thinking all along. Okay, so it now seems more achievable. There are still problems though, particularly around generics.

Function signatures will never really be possible to get right. Probably (...any[]) => any is the best we can do. Maybe we could use .length to help here slightly, but not much, and there are problems with that.
What type do we give generic collections? We could probably make Array<T> work by checking every element at runtime, that seems okay to have a special check for. But what about Map<K, V>, should we write a special checker for that too? And Set<T> too? What about custom collection classes people may write? The best we can do with those in the general case is make things any, but that could lead to incorrect results sometimes.
Any type that's distinguished by function signatures (as for example Map<K, V> is) will sometimes yield wrong results unless it has a specialised checker implementation.

// The best interface we could possibly generate under ideal conditions for a Map<K, V> without
// special code that knows to check the keys and values properties and set signatures accordingly.
// Comparing this against Map<string, number> is useless, it can't check those generics
interface $$tsstGeneratedInterface2OrWhatever {
    // More realistically this would be `get(...args: any[]): any;`
    // Ideally we could sometimes get some info from function decompilation
    get(key: any): any;
    set(key: any, value: any): any;
    ...
}

So, we can do a bit more than I originally thought, but I'm still pretty sure that the lack of signatures means a lot of real world scenarios will fail. If it can't be relied upon to work for everything, it's effectively useless.

Fair enough! Admittedly recursive objects hadn't really occurred to me. Admittedly in those cases things may get tougher. I'd argue even before reaching perfection this may still be useful though. Same as TS itself!

Functions

I'd suggested generic inference in #14078 before, which @masaeedu incorporated into a more pronounced proposal at #17428. So hopefully that'll improve, though perhaps the bigger problem for functions isn't even so much a TS one, but rather JS level function comparison. I imagine that's identity-based, which fails for testing purposes I suppose.
In that sense, I suppose realistically functions will likely end up having to be tested based on their results in practice, i.e. testing not the function directly, but a few applied versions so testing becomes doable again both for JS as well as for type inference purposes.

What type do we give generic collections?

So in these interface-value matching checks, the interface can be regarded as a LHS, the value as a RHS. That means in order to get the most realistic check, we'd prefer for the inferred type on the value to be as granular as possible, i.e. no widening if it can be avoided. This means we wouldn't infer Person[], but could infer [{ name: 'abc }, { name: 'def' }], i.e. a type that's essentially the value expressed in type literals. And that's fine, because we can use just that to match the interface.
Map / Set may be tough as their imperative implementation may not give much inference akin to the type literal representations of plain arrays/objects. Still though, doesn't need to be perfect to improve what we have now. :)

the bigger problem for functions isn't even so much a TS one, but rather JS level function comparison

Absolutely. The restrictions aren't in TS, they're in JS. The whole point of TS is to add extra type information that JS doesn't have, and we can't recover all of that from JS objects. That's unsolvable unless JS add type information.

doesn't need to be perfect to improve what we have now

I don't know, I think it might have to be. I don't personally see much value in a test with unreliable results.
Let's say we have the following interface somewhere in our source:
interface Foo {
    bar: string | number;
}

Okay, we can test that fine.
const foo = someFunctionThatShouldReturnFoo();

// Not what the actual syntax would be
expect( tsst(foo).is<Foo>() ).toBeTrue();

That works, we should be able to make tsst validate against that interface. But now let's say that we alter the code, and add a baz: Map<string, string>; property to Foo, but we accidentally return a Map<string, number> object as the property in someFunctionThatShouldReturnFoo.
Well now the test still passes because tsst can't access all the type information in the Map and we have a test that's incorrectly passing. In my book, a falsly passing test is worse than no test. We're really just trying to re-check what's already being done by the type checker here. It would be nice if we could, but I don't think it's possible.

The restrictions aren't in TS, they're in JS. [...] we can't recover all of that from JS objects.

fwiw, from (a, b) => a + b TS can infer... arity. the main JS problem isn't even this inference part though. it's that in Jest you can't just be like expect(fn).toEqual((a, b) => a + b) -- at run-time this would check identity-based equality, which isn't useful for the purpose of the intended check.
So there's a limitation there, but it's not even imposed by your additions. And heck, no-one's claimed Jest to be useless over this limitation yet. So essentially functions would instead be tested indirectly I guess. That works.
In fact, for ES6 Set/Map the exact same limitations apply -- the comparison doesn't even work at Jest's run-time as JS would apply identity-based equality checks.
Perhaps when we get something we can't compare (function/Set/Map) we could give some warning notifying the user part of the test is not meaningful (for either run-time or compile-time checks!). Functions could still be tested in separate tests applying them.
Admittedly sucks for Set / Map users, but given its imperative API it's been anathema for static type checking to begin with. I'd argue that's not on TS. Seems there was intent to improve on that at https://github.com/gcanti/fp-ts/issues/161, fwiw.

Hmm...
Throwing up warnings or failing when the checked interface doesn't comply with our restrictions is an option, but I think it would quickly get too abrasive for me to ever use. The interface/object comparison check idea is really just a convenience for testing the same things we currently check manually property-by-property using standard testing procedures. If we had to worry about tests breaking and having to be  rewritten if we choose to add one property to an interface that would completely negate the convenience for me.

Hm. Perhaps the reason I didn't feel as reluctant is I've personally largely avoided the ES6 structures (and say Immutable.js) in favor of plain structures, mostly since those seemed to work nicely with the functional paradigm offered by Ramda that static type checking kind of depends on.
Following that paradigm (separating logic and data), I wouldn't normally mix functions into such object structures either. In that sense, my own style would likely not have suffered much from these limitations.
I think the good part here is that JS limitations already means many of these cases would already have stayed out of Jest tests, but yeah, not Set/Map I guess.

That's fair. It's worth noting that it's more than just Set/Map though, it's  any object with function signatures at any depth. I think, putting it like that, that's a large swathe of all objects. Personally I'd feel uncomfortable writing a test that relied on that assumption unless I could guarantee that assumption would continue to hold as the codebase developed, too.
The basic problem is still one I'm interested in solving, but I'm not convinced this is the solution.

On second thought... the checks might be in place already. expect(fn).toEqual((a, b) => a + b) always fails at run-time due to identity checks, meaning no-one is likely to keep testing in this way 'any object with function signatures at any depth'. Note that prototype methods won't count btw.
So hopefully you have no more constraints than those already pre-imposed by the run-time side.

If I may bounce off an idea since you have a bit more experience here, could I say parse a typings lib and get its typings for different exports?
Use-case: use function info to allow the user to give a few params, and filter down the list of functions to those usable for those inputs.
I figured some FP libs like Ramda primarily face adoption issues from the learning curve of their overwhelming number of functions, so I figured it'd be cool if I could help users a bit find the functions they need.

Sorry, yet again something came up and I haven't got this done. I think I may have the time over the next couple of days, but I've learned not to make that commitment.

Use-case: use function info to allow the user to give a few params, and filter down the list of functions to those usable for those inputs.

That's an interesting idea, and I think the answer is yes, partially.
Pulling out all of the exports shouldn't be hard. TypeChecker.prototype.getExportsOfModule(moduleSymbol: ts.Symbol) exists, although I haven't used it. Otherwise it shouldn't be too hard to just traverse the file and find all of the export declarations. Filtering these exports down to the functions shouldn't be a problem.
You can get the signatures out of a function in a few ways, including from the type and from the declaration nodes. So getting a list of function names and their signatures shouldn't be too hard.
The place where it gets a little tricky is filtering those signatures. (str: string) => void shouldn't be too hard to deal with, but how you want to handle filtering of more complex parameter types I'm not sure. If you have a parameter type of string | number things are already a little tricky.
What format were you expecting the user to give params? Actual values? Strings representing types? Would this be running in an environment where you could use the compiler itself in your filtering interface?

Thanks! That seems exactly what I was looking for. :)

how you want to handle filtering of more complex parameter types I'm not sure.

This part I'd considered already. I fear this becomes just brute-forcing the potential positions of known input parameters (or rather, their types) to check if any work. :)

Would this be running in an environment where you could use the compiler itself in your filtering interface?

I'd imagine the TS compiler would be loaded into the browser here, yeah. I looked at JSDoc data as an alternative way to check function signatures (over TS), but those seem to lack even basic meta like function names.

What format were you expecting the user to give params? Actual values? Strings representing types?

Values. The idea would be to just execute the legitimate options so the user could just see the actual results by function (+ param order, if multiple match).

Well good luck, and be warned that matching the signatures may prove quite hard, I'm not sure how I'd do that. The language service also provides some methods for autocompletion that may be of interest here. I don't think that would give you the info you want directly, but the source of methods like getCompletionsAtPosition might be worth a read.

Tried for a bit, but I did still run into bumps, yeah.
Could you publish a recent-ish version of tsst to npm again? Then I'll put that as the dep here.

Right, yeah, sorry. I've had about four other high priority projects going on and couldn't particularly justify throwing time into this fun side thing, but you're waiting on it and I said I would so I'll get something out today/tomorrow. I'm actually just heading to bed, but I'll work on this first thing and get out a basic MVP.

Eh, if I needed something changed I should just try and add it myself, it's just the npm repo isn't mine to publish to. :)

Hey, so just an update because I'm late again. I went to do that and found there was a significant bug still in it that I'd forgotten I'd only got half way through fixing, so it wasn't actually functioning at all. It's a little more work to get a releasable version than I'd thought, but I am actively working on it when I can. I'll tentatively say a day or two.

Would it be doable to just git checkout the version before the refactor and publish that? I hope that should help alleviate pressure on your end.


[BUG]

Reproduction steps
Dear devs .
Im facing a issue on the commissioning part of esp 32 with client has chip-tool,
While i pass
$ ./chip-tool pairing ble-wifi <node_id>   <pin_code>
im facing opcreds based  error.
Here are the log files
https://github.com/aravindone/aravindone/blob/main/Qr code feed log commission state
Bug prevalence
every time
GitHub hash of the SDK that was being used
ac810b186ed4f954323afd804cd4d1465ed8b6f2
Platform
esp32
Platform Version(s)
1.1.0-1.1
Anything else?
No response

@aravindone Those log file links both link to https://github.com/project-chip/connectedhomeip/issues/url which is not very helpful.

@aravindone Those log file links both link to https://github.com/project-chip/connectedhomeip/issues/url which is not very helpful.

now i have uploaded the logs @bzbarsky-apple

@aravindone Link was still broken, but I fixed it....
What that log is showing is that the BLE scan starts, no Matter devices are discovered, and commissioning times out.:
[1683639733.670439][33684:33687] CHIP:CTL: Commissioning discovery over BLE failed: ../examples/chip-tool/third_party/connectedhomeip/src/platform/Linux/BLEManagerImpl.cpp:787: CHIP Error 0x00000032: Timeout

There's nothing there about opcreds.

@aravindone Link was still broken, but I fixed it....
What that log is showing is that the BLE scan starts, no Matter devices are discovered, and commissioning times out.:
[1683639733.670439][33684:33687] CHIP:CTL: Commissioning discovery over BLE failed: ../examples/chip-tool/third_party/connectedhomeip/src/platform/Linux/BLEManagerImpl.cpp:787: CHIP Error 0x00000032: Timeout

There's nothing there about opcreds.

@bzbarsky-apple i have missed this log now you can have look

OK, so in the new log what we have is commissioning going along until chip-tool sends a AddOrUpdateWiFiNetwork command and the server responds with INVALID_COMMAND.  Then commissining fails.
On the server side, all the log says for this part is:
I (15888) chip[EM]: >>> [E:45714r M:106803610] (S) Msg RX from 1:FFFFFFFB00000000 [B6E0] --- Type 0001:08 (IM:InvokeCommandRequest)
I (15898) chip[EM]: <<< [E:45714r M:154830294] (S) Msg TX to 1:FFFFFFFB00000000 [B6E0] --- Type 0001:09 (IM:InvokeCommandResponse)

Why the device decided to respond this way... I don't know.  The esp32 all-clusters-app should have a working network commissioning implementation, last I checked, which this device certainly does not seem to.

@bzbarsky-apple which tool is giving this issue ? . is the problem is with the chip-tool or from the Esp 32 all cluster app ?

The problem is from the device side, so from the all-clusters-app if that's what the device is running.

Hi @bzbarsky-apple  This time i tried with ligthing-app example im getting failed with
E (240190) chip[ZCL]: OpCreds: Got FailSafeTimerExpired E (240190) chip[ZCL]: OpCreds: Proceeding to FailSafeCleanup on fail-safe expiry!
here are the logs.
https://raw.githubusercontent.com/aravindone/aravindone/main/chiptool_logs
https://raw.githubusercontent.com/aravindone/aravindone/main/comissioning failure (ble-wifi) log esp

@aravindone That log shows that chip-tool sent ConnectNetwork and the device responded with NetworkNotFound. Then chip-tool gave up on the commissioning, and eventually the fail-safe timed out.
What's odd is that the device log sure seems to show it joining a network, so why did it respond with NetworkNotFound?

im closing the ticket because the issue was resolved using direct ubuntu laptop


mWeb - After redirect to ND again loop starts to connect to plaid

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue was found executing #13236
Action Performed:

Go to NewDot and login
Go to Workspace - Connect bank account
Tap Connect online with Plaid
Select Chase, input credentials
Select Plaid checking account and submit

Expected Result:
User should be redirected to NewDot to proceed with bank account details
Actual Result:
NewDot appears for a second and then plaid loop starts again
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / Chrome

Version Number: 1.2.58-3
Reproducible in staging?: y
Reproducible in production?: not able to check
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/214384690-0a70cef5-dcbd-418c-895c-f19a8efe98b2.mp4
Expensify/Expensify Issue URL:
Issue reported by: applause internal team
Slack conversation:
View all open jobs on GitHub

Hi @kavimuru - I'm not able to test this I don't think. Every time I follow your testing steps to choose Chase, I'm taking to Chase, instead of First Platypus Bank.

@kavimuru Eep! 4 days overdue now. Issues have feelings too...

@kavimuru Huh... This is 4 days overdue. Who can take care of this?

@kavimuru Huh... This is 4 days overdue. Who can take care of this?

@kavimuru this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

@kavimuru Still overdue 6 days?! Let's take care of this!

@kavimuru Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

@kavimuru 12 days overdue. Walking. Toward. The. Light...

Bump again @kavimuru. I'm really not sure how to recreate this.

@twisterdotcom Sorry,not able to reproduce now.

Let's close!

Be sure to fill out the Contact List!


Restore PhotoCardDesktop and PhotoCardMobile

Overview
The SupportUs page references PhotoCardDesktop and PhotoCardMobile, but those components don't currently exist in the code base.
Action Items
Restore or implement PhotoCard components
Resources/Instructions
https://www.figma.com/file/EFoSuj1b9G4aZ7bN8OX8tf/CivicTechIndex---Master-Design-File?node-id=4747%3A20563

PR I just did should fix this


scene example only shows a gray window.

The scene example shows only an empty, completely gray, window for me. I dont see any objects, not even if I modify the scene and the app reloads it.. Happens with and without --release.
$ cargo run --example scene --release
    Finished release [optimized] target(s) in 0.24s
     Running `target/release/examples/scene`
[
  (
    entity: 965537340,
    components: [
      {
        "type": "ComponentB",
        "map": {
          "value": "hello",
        },
      },
      {
        "type": "ComponentA",
        "map": {
          "x": 1.0,
          "y": 2.0,
        },
      },
    ],
  ),
  (
    entity: 814248834,
    components: [
      {
        "type": "ComponentA",
        "map": {
          "x": 3.0,
          "y": 4.0,
        },
      },
    ],
  ),
]
  Entity(328997855)
    ComponentA: { x: 3 y: 4 }

  Entity(1154439664)
    ComponentA: { x: 3 y: 4 }

  Entity(404566393)
    ComponentA: { x: 1 y: 2 }

  Entity(837292325)
    ComponentA: { x: 1 y: 2 }

Current version of the repo (latest one right now): a7f1889a35f93b13edc2b1233189656289b0448e
$ rustc --version
rustc 1.45.2 (d3fb005a3 2020-07-31)
$ cargo --version
cargo 1.33.0

Do you also need other software versions / system specs? Other examples seem to work fine, even the breakout game works.

For that example that is the expected behaviour. None of the entities have components that have a visual representation and no camera is present in the scene either.
I believe the purpose of the scene example is to show how to load a scn file with custom components and that hot-reloading works with scene files too (try changing the values in the file and watch the output in the console).
This is not an issue in itself, but it hints that the purpose of this example could be made clearer!

I actually launched it hoping to see a scene too. :) So +1. Maybe a name e.g. serialisation is more apt?

I see. Maybe it would be a great idea to include a Camera then so that the user also "sees" that it is really working and changing the world?

Maybe there can be some Texts on the screen that display the values of the components loaded from the scene file with a hint "Try changing assets/scene/load_scene_example.scn" or something along the line of that?

I have created a PR which adds a simple message telling the user to look at the console output. This should at least show the user that there should be no content in the UI window.

Hehe, I too was expecting the video from https://bevyengine.org/news/introducing-bevy/ before I read the source code of that example :D

Hehe, I too was expecting the video from https://bevyengine.org/news/introducing-bevy/ before I read the source code of that example :D

Exactly!

Resolved by #181. Thanks!


soundfile: Fix build on aarch64-darwin

Motivation for this change
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/748

All suggestions applied, please review the new changes.

All suggestions applied, please review the new changes.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 161668 run on x86_64-linux 1

1 package failed to build and already failed to build on hydra master:

python39Packages.elegy: log was empty

4 packages built:

python310Packages.soundfile (python310Packages.pysoundfile)
python39Packages.coqui-trainer
python39Packages.librosa
python39Packages.soundfile (python39Packages.pysoundfile)


Add logging to understand when PHDs filter results

Since Simple Report is responsible for sending users' single test results, we want to log a list of PHD filters so that we can better understand how we might assist users in getting their data to the proper sources.
Technical Considerations:

Minimum window for observation: 1 week

Acceptance Criteria:

Log "destinations" and associated errors
Sharing learnings

Additional Questions:

If we want to persist additional information from logs, what would be the pattern (across all of SR)?

We now log the full report stream response.  There isn't any information coming back from the response in prod that we weren't seeing in the lower envs (destinations, etc) that would have been useful for read receipts.


fix null safe check in RenderIndexedStack

Fixes https://github.com/flutter/flutter/issues/107481
The affected code was introduced in https://github.com/flutter/flutter/commit/36a8f0f2ae01701a451846e5696a64678b0c8011, where I think a ! was used where it was neither necessary nor correct to do so (since it is valid to have _index == null)

@goderbauer can you validate this is the correct change? I'm assuming this should handle null per reading the dartdocs.


How do you run the frontend ?

The readme doesn't cover how to run the front-end and anything I try from package.json throws errors.
F.ex.
npm i

npm run dev

Could not resolve "@ant-design/icons/es/icons/EyeOutlined"

Please check the last build log, I have added web project build as well.

I'm sure what this error triggered. Generally there's some kind of a dependency on ant-design in here:
https://github.com/search?q=repo%3Aandissanayake%2FUnifiedApp ant-design&type=code
but I've now move on with the codebase quite a bit so unfortunatelly cannot reproduce anymore.

This issue is due to package-lock.json. I have removed that. Thank you @jektvik for bringing this to our attention.


Awesome artical

I would like an SVG version of the architectural diagram.

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID # 453213

Hello,
Which article are you referencing with this comment?
Thank you!
David

Closing as follow up went unanswered


[release-0.18] Fix controller generating cilium manifests with registry mirror (#7170)

Issue #, if available:
Description of changes:
This is a manual cherry pick of #7170
Testing (if applicable):
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/test all

/test eks-anywhere-presubmit

/lgtm

/approve


[Event Parameter Change] Page 344 - Navigate - procedure OnFindRecords - event OnFindRecordsOnBeforeMessagePostingDateFilter

We would like the parameter IsHandled added to the following event. The variable was created, but not used.
Page 344 - Navigate - procedure OnFindRecords - event OnFindRecordsOnBeforeMessagePostingDateFilter
Original:
end else begin
    IsHandled := false;
    OnFindRecordsOnBeforeMessagePostingDateFilter(Rec, PostingDateFilter, IsHandled);
    if PostingDateFilter = '' then
        Message(Text013)
    else
        Message(Text014);
end;

[IntegrationEvent(false, false)]
local procedure OnFindRecordsOnBeforeMessagePostingDateFilter(DocumentEntry: Record "Document Entry"; PostingDateFilter: Text; IsHandled: Boolean)
begin
end;

Change: Code with IsHandled
end else begin
    IsHandled := false;
    OnFindRecordsOnBeforeMessagePostingDateFilter(Rec, PostingDateFilter, IsHandled);

    if not IsHandled then // <-- ADDED

        if PostingDateFilter = '' then
            Message(Text013)
        else
            Message(Text014);
end;

[IntegrationEvent(false, false)]
local procedure OnFindRecordsOnBeforeMessagePostingDateFilter(DocumentEntry: Record "Document Entry"; PostingDateFilter: Text; var IsHandled: Boolean) // <-- IsHandled has to be var
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 49416.


[Steam Deck] GAMESCOPE_OVERRIDE_REFRESH_RATE has no effect

I have Steam Deck (non-OLED, 512GB version) and BazziteOS (latest) with KDE/Plasma DE.
Adding GAMESCOPE_OVERRIDE_REFRESH_RATE=40,70 to /etc/environment has no effect.
When I was using SteamOS, I was able to overclock the display to 70Hz, but I cannot do this with BazziteOS. On top of that, the script that I've used in SteamOS does not work in BazziteOS as it is simply non-compatible.
Any advise?

Can confirm it doesn't work on my end. No solutions found for now.

This also has no effect for me. Using deck image on HTPC connected to LG OLED TV. 120hz works in desktop mode no problem, but gaming mode is locked to 60hz\60fps.
I added 'GAMESCOPE_OVERRIDE_REFRESH_RATE=60,70,80,90,100,110,120' to /etc/environment.
> echo $GAMESCOPE_OVERRIDE_REFRESH_RATE
> 60,70,80,90,100,110,120

Some combination of these changes got me to my desired refresh rate. I still thing there is some work needed to get 120 consistently? See notes about RDR2 below.
I  added this to /etc/environment, along with the aforementioned GAMESCOPE_OVERRIDE_REFRESH_RATE

STEAM_DISPLAY_REFRESH_LIMITS=60,120

In Gaming Mode > Settings > Display > Disabled Universal Frame Rate Control (I forget the exact name. It's at the bottom. Might need to enable Developer Mode).
After these changes (and possibly a reboot) I was able to see two things in gaming mode performance overlay:

FPS Limit slider going to 120
Refresh Rate slider going to 120hz

I was using Red Dead Redemption II to test. However, for some reason that game is locked to 60hz, and I cannot change it in graphics settings. Maybe some other gamescope setting will help?
So I tested  random 2d game (Nartia Boy), and per gamescope performance overlay, i was hitting 120.

I'm using an i5 12400f + amd 7800xt and philips oled 807, the refresh mode can be 60 or 120 Hz, and everything is fine, but for some games, it would be very suitable to have 75 or 90Hz, I would like to control it. Because I balance between quality, performance and noise. And it would be great to have all the options to customize this. (for example, frame generator + refresh rate limitation, to minimize power consumption). I'm trying to set various environment variables. I'm reading the Refresh Rate Unlocker script and so far I can't add a new value to gamescore(
I will be glad of any help


Stream Idle Timer Fires Even When Stream Was Active

Description:
Envoy should not fire stream idle timer when it's active.
Repro steps:

create a listener with stream_idle_timeout set to 60s
a client with a low bandwidth network download a file through Envoy proxy, curl -v -k --limit-rate 1 https://localhost:7443/2MB.txt -o 2MB.txt
after about 65 seconds, envoy close the connection and output an access log with an SI flag in it: [2024-05-09T03:15:14.949Z] "GET /2MB.txt HTTP/1.1" 200 SI 0<PHONE_NUMBER>0 2 "<IP_ADDRESS>" "curl/8.6.0" "bc69c5d5-e27e-4809-aac4-420acaae5b47" "localhost:7443" "<IP_ADDRESS>:8080"

Admin and Stats Output:

stats: stats.log
clusters: clusters.log
routes: routes.log
server info: server_info.log

Config:
- name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          use_remote_address: true
          normalize_path: true
          merge_slashes: true
          path_with_escaped_slashes_action: UNESCAPE_AND_REDIRECT
          request_timeout: 1200s
          request_headers_timeout: 65s
          stream_idle_timeout: 60s
          common_http_protocol_options:
            max_stream_duration: 3600s
            idle_timeout: 70s
          http2_protocol_options:
            max_concurrent_streams: 100
            initial_stream_window_size: 65536 # 64 KiB
            initial_connection_window_size: 1048576 # 1 MiB
          access_log:
          - name: envoy.access_loggers.file
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: "debug/logs/access_7443.log"
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
          route_config:
            virtual_hosts:
            - name: default
              domains: ["*"]
              routes:
              - match: {prefix: "/"}
                route:
                  cluster: service_foo
                  timeout: 3600s

Logs:

debug log: stdout.log

[2024-05-09 11:15:14.963][11636530][debug][http] [source/common/http/conn_manager_impl.cc:1939] [Tags: "ConnectionId":"0","StreamId"     :"13380574157739000950"] Disabling upstream stream due to downstream stream watermark.

For a slow downstream, stream buffer's watermark is high and it takes a long time to recover to low. During this time client is downloading slowly but Envoy won't receive from upstream and won't reset its idle timer.
In my case the client is an IoT device with a 4kbps bandwidth. Envoy's per_connection_buffer_limit_bytes is set to 32 KB. So it takes 32 seconds (32KB / 2 / (4kbps / 8)) to return to low watermark. But if the connection buffer is higher it may take much more time.

The issue can be mitigated by either increasing the stream_idle_timeout or decreasing the per_connection_buffer_limit_bytes, if applicable to the use case.

cc @alyssawilk @mattklein123


Move demangle filter to an optional module

Demangling is not a requirement for crash reports that are later passed through the symbolicator (with dSYMs).
To reduce minimal library size and exclude parts of swift/llvm code base, this module becomes optional.

I'm also curious about how users will install KSCrash by default, as they might have expected that demangling worked by default. It seems like most of the users would still need it, so I'm wondering how we can make that as easy as possible for them.

I'm also curious about how users will install KSCrash by default, as they might have expected that demangling worked by default. It seems like most of the users would still need it, so I'm wondering how we can make that as easy as possible for them. Also, I think we should update README as well.

It's a valid concern. I've added demangling to Installations API and made it enabled by-default. So those who were using installations can keep this functionality without extra efforts. And I've updated the README to highlight that this is now not a default behavior.
Also, we'll need a "migration guide" for 2.0 anyway as there are other breaking changes and we need to highlight the expected app code updates.


How to configure GPIO 32 and 33 as input or output in ESP32 (IDFGH-1488)

Hi
How i can configure GPIO 32 and 33 as input or output in ESP32, I tried for all other gpio, those are working, Can anyone give some suggestion.
Thanks

Use gpio_config or call rtc_gpio_deinit first
Possibly similar to https://github.com/espressif/esp-idf/issues/245

What does your code fragment look like today for setting GPIOs?  It is likely that you are running into issues because a uint32_t is 32 bits in length (eg. pins 0-31) but when you are setting GPIO 32 or 33, that won't fit in a bitmask that is only 32 bits long.  gpio_config() is the ideal way to go or else use gpio_pad_select_gpio().

Hi
Thanks for the replies, I checked with 'gpio_pad_select_gpio() followed by ' 'rtc_gpio_deinit'  operation.Now both GPIO 32&33 also i am able to use as gpios.

Howdy Amallal, Great news.  Remember to close the issue if you no longer need a response and you consider the issue closed ... or else update the issue with any continuance on the same subject.

To be a bit more explicit with regards to what @nkolban said (since I just struggled through this), you can setup your GPIO pins > 32 with something like this:
// We use unsigned long here since 32 is a long
#define GPIO_BIT_MASK  ((1ULL<<GPIO_NUM_32) | (1ULL<<GPIO_NUM_33))

app_main() {
	gpio_config_t io_conf;
	io_conf.intr_type = GPIO_INTR_DISABLE;
	io_conf.mode = GPIO_MODE_OUTPUT;
	io_conf.pin_bit_mask = GPIO_BIT_MASK;
	io_conf.pull_down_en = GPIO_PULLDOWN_DISABLE;
	io_conf.pull_up_en = GPIO_PULLUP_DISABLE;
	gpio_config(&io_conf);
}

🌟

FWIW, if you came here like I did trying to see why GPIO32 and GPIO33 won't work right specifically on the ESP-WROVER-KIT (with LCD) despite this, it's because in that particular implementation those pins are being used for an external crystal.

Before an ESP32 pin can be used as input or output. In ESP32 framework (not Arduino framework) this must be configured by calling gpio_config () This function accepts as the only parameter a gpio_config_t structure with five members that must be completely filled.
To set a pin as output, you must disable the modes "Interruption" "pull Up" and "pull Down", which would be rather input modes. You must configure the mode as "output mode" and you must specify which pins these changes affect using pin_bit_mask
`gpio_config_t io_conf;
io_conf.intr_type = GPIO_PIN_INTR_DISABLE;//disable interrupt
io_conf.mode = GPIO_MODE_OUTPUT;//set as output mode
io_conf.pin_bit_mask = (1ULL<<18);//bit mask of the pins that you want to set,e.g.GPIO18
io_conf.pull_down_en = GPIO_PULLDOWN_DISABLE;//disable pull-down mode
io_conf.pull_up_en = GPIO_PULLUP_DISABLE;//disable pull-up mode
esp_err_t error=gpio_config(&io_conf);//configure GPIO with the given settings

if(error!=ESP_OK){
    printf("error configuring outputs \n");
}`

To set a pin as input, You must put the mode ( io_conf.mode )as input and select if you want the low level to be interpreted as active or inactive using pull_down_en
io_conf.intr_type = GPIO_PIN_INTR_DISABLE;//disable interrupt
io_conf.mode = GPIO_MODE_INPUT;//set as inputmode
io_conf.pin_bit_mask = (1ULL<<15);//bit mask of the pins that you want to set,e.g.GPIO15
io_conf.pull_down_en = GPIO_PULLDOWN_ENABLE;//enable pull-down mode
io_conf.pull_up_en = GPIO_PULLUP_DISABLE;//disable pull-up mode
esp_err_t error=gpio_config(&io_conf);//configure GPIO with the given settings

if(error!=ESP_OK){
    printf("error configuring inputs\n");
}

to turn on the output 18: gpio_set_level(18, cnt );
to detect the input 15:int level=gpio_get_level(15);
take a look at the espressif official website about GPIO

Right, but if your device has a crystal on those lines like the wrover kit does, it won't work no matter what you do.

Right, but if your device has a crystal on those lines like the wrover kit does, it won't work no matter what you do.
What development boards can you use these pins on? WROOM?

What development boards can you use these pins on? WROOM?

I'm not sure what WROOM-based board you are referring to... per the DEVKIT-C schematics, it doesn't appear to use an external crystal.
OTOH looking at the WROVER-KIT schematic near the top right, we see the crystal (and a cryptic note about certain resistors R36-R39 that doesn't make much sense to me). Short of desoldering things that one's using an external crystal on the usual GPIO 33/34 pins.
So, check the schematics for the board of interest to see if it uses an external crystal or not. It seems like they usually don't - I have no idea why they bother to on the WROVER-KIT except perhaps for possibly tighter timing.

What development boards can you use these pins on? WROOM?

So, check the schematics for the board of interest to see if it uses an external crystal or not. It seems like they usually don't - I have no idea why they bother to on the WROVER-KIT except perhaps for possibly tighter timing.

It turns out that on the ESP32 DEVKIT V1 WROOM board you will not be able to control pins 32 and 33?

Is this the exact board you're talking about? https://github.com/espressif/arduino-esp32/issues/544
I don't see any crystal on that particular schematic so I'd think GPIO32 and 33 would work fine.
If this is not the board you're talking about, share the schematic and let's take a look.

Is this the exact board you're talking about? espressif/arduino-esp32#544
I don't see any crystal on that particular schematic so I'd think GPIO32 and 33 would work fine.
If this is not the board you're talking about, share the schematic and let's take a look.

Yes, the board looks exactly the same from above. Only the bottom is black :) But digitalWrite (32, HIGH);     digitalWrite (33, HIGH); does not work.
Even if you do pinMode this way:
void aPinMode(int pinNum, int pinDir) {
  // Enable GPIO32 or 33 as output.
  if (pinNum == 32 || pinNum == 33) {
    uint64_t gpioBitMask = (pinNum == 32) ? 1ULL << GPIO_NUM_32 : 1ULL << GPIO_NUM_33;
    gpio_mode_t gpioMode = (pinDir == OUTPUT) ? GPIO_MODE_OUTPUT : GPIO_MODE_INPUT;
    gpio_config_t io_conf;
    io_conf.intr_type = GPIO_INTR_DISABLE;
    io_conf.mode = gpioMode;
    io_conf.pin_bit_mask = gpioBitMask;
    io_conf.pull_down_en = GPIO_PULLDOWN_DISABLE;
    io_conf.pull_up_en = GPIO_PULLUP_DISABLE;
    gpio_config(&io_conf);
  } else pinMode(pinNum, pinDir);
}

I was using BIT(GPIO) as a generic format, I exchanged it with 1ULL << GPIO and then alles ok :) @nkolban Thank you for pointing out the 31 Bit mask limit, I just fixed a bug :+1:


Made isPad and isPhone more robust and future-proof.

Had a problem where isPad was failing to detect the new iPad pro 10.5 inch. When i checked the code i saw that isPad checks device per device and at the time of checking out DeviceKit via pods this device was not added yet to the master branch.
The current way to check for isPad is fragile to the Apple product release schedule and leaves possible problems for apps released before a new device is added to the list.
This change is aimed at making this check more simple and future-proof.
NOTE : Will fail if running iPhone app on compatibility mode on iPad

Hm yeah you're right ... is it maybe even better to parse the .unknown associated value for iPad or iPhone (or/and even iPod) so that we have the benefit of both: being better prepared for new devices and also showing iPads as iPads and iPhones as iPhones? But, err, even though it was bad for you: thanks for running into this :) this is a very important bug/edge case!


feat: Added the /verify page UI

Description
I have added the /verify page UI with some comment's.
Checklist:

[x] This pull request follow our contribution guidelines
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation (postman and swagger)
[ ] I have written tests for the code
[ ] I have updated .env.example file for new .env variables

Closes #47
Screenshots

Screen's Above 1024px

Screen's Below 1024px

@Karol-Ari Which texts would you like me to make changes on Karol.

If you look at figma texts then you will see

Pull Request Closed Due to Branch Conflict's.


Rebuild for GSL 2.5

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Will close #73 if it passes tests

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Add constraints with identifiers to the R file

@sdevos mentioned that identifiers are not really made for lookups, so should think about whether this is really a good idea.

What's the additional value compare to IBOutlet ?

Yeah, that would be minimal. IBOutlet or just keeping the reference in code if you create it there would be preferable. Identifiers would be more of a debugging thing.

I'll close this one, unless someone can make a good case for it. :) Too much downsides and no real win.


TypeError: apolloProvider.prefetchAll  in<EMAIL_ADDRESS>

If I ran fresh npm install<EMAIL_ADDRESS>will be installed.
When running the application, the app will die from TypeError: apolloProvider.prefetchAll is not a function
However npm i -S<EMAIL_ADDRESS>fixed this issue.

This question is available on Nuxt community (#c137)

Check out my issue from yesterday: https://cmty.app/nuxt/apollo-module/issues/c134
A quick fix is to use resolutions in your package.json file to explicitly reference beta.16 (non-breaking) until a new version of this module is released.
@dohomi my suggestion would be to nix the ^ since vue-apollo is technically in beta and breaking changes are excusable.

@bjunc @nodegin could you guys verify if the https://github.com/nuxt-community/apollo-module/pull/158 is fixing your issue?

Hello,
npm i nuxt-community/apollo-module#vue-apollo-upgrade-beta-21
Seems to fix my error "apolloProvider.prefetchAll is not a function".
Thanks, I'll stick on this branch until this module release a new version, thanks

@dohomi I got it working now with npm i nuxt-community/apollo-module#vue-apollo-upgrade-beta-21 and<EMAIL_ADDRESS>However another error thrown on console:
TypeError: Cannot read property '$ssrContext' of undefined
In addition I am facing another issue now, in stable release (^4.0.0-rc1 and vue-apollo@3.0.0-beta.19), the onLogin token expire is not able to use, the cookie will always expire in past, but with latest update things looks normal except the console error message... Wishing the new update will come out soon

vue-apollo released beta.22 fixes this bug.

Not fixed at all. Please reopen.

@ishitatsuyuki I just updated the dependency in #158 can you check if this resolves your issue?

@dohomi working for me. Thanks

I think you can update it and publish a new version @dohomi :)

Unfortunately, it seems "vue-apollo": "3.0.0-beta.25" has reintroduced the issue. I pinned the version by resolutions to fix the class-component issue (2 days ago, wasn't it?).

@ApricumMedia see my comments in https://github.com/nuxt-community/apollo-module/pull/158
I'm not sure which version is suitable - I run the apollo-module rc1 and vue-apollo beta.19 at the moment

@dohomi why are you using ^ caret inside the versioning? Maybe it would be a better idea to remove that caret so all people that use your package could at least be sure that it won't break by itself by upgrading to newer versions of vue-apollo versions you don't support?
What I suggest is switch
"vue-apollo": "^3.0.0-beta.19"
to
"vue-apollo": "3.0.0-beta.19",

@AndrewBogdanovTSS the reason is first that there hasn't been any breaking change for the past 10 months while working with vue-apollo. I thought 3 days ago I could ship rc2 with the most current changes - now everything seems to be delayed with fixes. But yeah... you are right I'll release rc2 temporarily with beta.19 later the evening

@dohomi Despite all the nagging, your work on the module is still highly appreciated, Dominic — just wanted to leave you a thanks for that.

did I mention that rc2 is out? Hopefully rc3 will follow over the weekend.. I know that the naming convention is a bit off because this module relies on vue-apollo which by itself declares in beta. But for sure there will be stable releases coming up soon with less breaking changes and fiddling around

@dohomi any news about RC3 ?

rc3 is just published. It has still some issues with Nuxt v2, check out the newest issues. But for Nuxt 1.4.x everything is now updated to most recent versions of vue-apollo and the cli client

@dohomi Still seeing some strange errors in console in rc3

@nodegin which errors do you face?

@dohomi depends on which nuxt page, I have used head, asyncData methods

What's the status with nuxt 2 support? I can't use resolutions since I'm using npm, not yarn, and just about every version I tried is installing beta.28 of vue-apollo, which seems to have this problem. Even if I manually install a different version of vue-apollo


Get-DbaDbExtentDiff

Type of Change

[ ] Bug fix (non-breaking change, fixes #)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose

Approach

Commands to test

Screenshots

Learning

BTW, I'm thinking if we shouldn't outright convert the whole thing to powershell.
Most of the intricacies there come from limitations of TSSQL that PS can easily shortcircuit.
We'd still point to Paul's post as a reference, but there's really no need of all the boilerplate if we can do it in a few PS lines.

looks wondeful syntactically. Lemme throw at it some backends to see if all is good and glorious as it seems ;-)

small hiccups detected, posted proposal in PM

@niphlod, thanks a lot for your help with this function. Let's hope people will find it useful!

thank you both! 🙇


May be create a more "shareable" ecosystem for plop?

I just met plop. And I am in love with it.
Why I choose Plop over Yeoman?
Because it is composable, I can set a project by calling some third party plops (#20) and also add my owns, right on this way:
module.exports = function (plop) {
  require('plop-generator-react')(plop);
  require('plop-generator-redux')(plop);

  // Custom generators here...
};

So my proposal is: why not creating a website for Plop? And may be list the community created Plops?
Cheers :).

:+1: I agree, plop is awesome and this would greatly help make it seem more professional and polished.
We're going to use it for react-boilerplate v3, and I'd love to showcase it a bit in the documentation because I think it's awesome.

Agreed! I've been thinking about how best to do something like this. The main challenge is finding a way to do it that preserves the simplicity and customizability of plop. Maybe just being able to modify the generators in your own code after they are required is enough. So if the required generator has a path of /app/components/{{ camelCase name }}.js, you would be able to change that to match your project preference.
Thoughts?
Thanks for your input @mxstbr and @kevin-wolf. :smile:

Maybe making setGenerator return a callback that accepts options would make usage nice, something like this:
module.exports = (plop) => {
  plop.setGenerator('component', (options) => {
    const componentPath = options.componentPath || 'default/componentPath';

    return {
      description: 'bla',
      prompts: [],
      actions: (data) => {
        return [{
          type: 'add',
          path: componentPath,
          templateFile: 'someTemplate.hbs'
        }]
      },
    }
  }
};

which would allow you to use it like this to pass your desired path for the component generator like so:
require('plop-generator-react')({
  componentPath: 'bla/{{ properCase name }}/index.js'
})

This is a very flexible solution, as generator authors could have you customize everything they want you to customize, since they dictate which options they accept and which one's they don't accept.

Or may be a way to set configuration into the plop object, something like this:
module.exports = function (plop) {
  plop.configs = {}; // All your configs.

  require('plop-generator-react')(plop);
  require('plop-generator-redux')(plop);
};

Yeah that could work too and would probably require less rewriting!

I think a combination of the 2 might work out nicely. What if we changed the plopfile interface to optionally accept a config object for that file? In the case of shared generators, they could be developed and distributed in a more granular fashion which would allow users to mix and match. Then each module developer could create their own interface for that config file and basically provide a way to customize the functionality.
so a module would look something like this...
module.exports = function (plop, config) {
    var configDefaults = {basePath: 'src/modules'};
    var cfg = Object.assign({}, configDefaults, config);
    plop.setGenerator('basics', {
        description: 'this is a skeleton plopfile',
        prompts: [...],
        actions: [{
            type: 'add',
            path: cfg.basePath + '/something.js',
            ...etc
        }]
    });
};

and would be used like this...
module.exports = function (plop) {
    require('plop-generator-react')(plop, {basePath: 'app/mods'});
    require('plop-generator-redux')(plop, {basePath: 'app/models'});
};

actually, now that I look at this, I believe this would even work today. The only work would be to build the site and solidify the approach so that everyone knows what to expect from shared generators. :smile: I haven't tested it, but I don't believe this would even require a refactor.

this is finally complete, take a look at plop.load. Also you can look at the very basic code for the plop-pack I published in order to test this all out.

The first version of the website is finally out there. No list of community plop assets yet, but it's definitely on the radar. http://plopjs.com


You can check 'Free' and 'Paid' in sort menu

Instead, free and paid should cancel each other out.

Very good observation!

Had a weird git problem but latest PR fixes


[new-objects] Build is broken due to changed node definition file

The current node.d.ts in DefinitelyTyped uses TS 1.6 conventions, whereas we use TS 1.5
We should:

Upgrade to TS 1.6.
Use tsd instead of bower to pull in DefinitelyTyped definitions, which depends on specific versions of the definitions files to prevent breakages in the future.

I've done this in a local branch, but I've conflated several changes, so it's blocked on a few other updates I'm making to the build process.

Fixed.


Issue with Right-Click Behavior on Scrollbar

I've encountered a bug. When right-clicking the scrollbar and subsequently moving the mouse, the scrollbar starts scrolling. This behavior is unexpected as right-click interactions typically do not involve scrolling functionality. The expected behavior would be for the scrollbar to remain static during right-click actions.
Steps to Reproduce:

Right-click on the scrollbar.
Single click outside to hide context menu
Move the mouse without clicking any buttons

Expected Behavior:
The scrollbar should not move or scroll when right-clicked and dragged.
Actual Behavior:
The scrollbar starts scrolling when it is right-clicked and the mouse is moved.
Environment: MacOs
Version of react-custom-scrollbars-2 used: Latest
Browser and Version: Version 120.0.6099.216 (Official Build) (arm64)
OS and Version: Mac OS 14.2.1
I have attached a screen record below.
https://github.com/RobPethick/react-custom-scrollbars-2/assets/10485165/5f627b97-a80c-4376-b729-44f55449fb51

hi @RobPethick
Can I take on the task of resolving this issue?


names after wasmparser and wasm_encoder round trip

I've noticed that the names of functions can sometimes be slightly different after a wasmparser -> wasm_encoder roundtrip.
For example:
Original name:
(func $#func67<_ZN4core3ptr191drop_in_place$LT$std..sync..poison..PoisonError$LT$std..sync..mutex..MutexGuard$LT$alloc..vec..Vec$LT$$LP$spin_sdk..wit..wasi..io..poll..Pollable$C$core..task..wake..Waker$RP$$GT$$GT$$GT$$GT$17h4e207d90019cfe5eE> (@name "_ZN4core3ptr191drop_in_place$LT$std..sync..poison..PoisonError$LT$std..sync..mutex..MutexGuard$LT$alloc..vec..Vec$LT$$LP$spin_sdk..wit..wasi..io..poll..Pollable$C$core..task..wake..Waker$RP$$GT$$GT$$GT$$GT$17h4e207d90019cfe5eE") (;67;) (type 1) (param i32)

New name:
(func $"#func67 _ZN4core3ptr191drop_in_place$LT$std..sync..poison..PoisonError$LT$std..sync..mutex..MutexGuard$LT$alloc..vec..Vec$LT$$LP$spin_sdk..wit..wasi..io..poll..Pollable$C$core..task..wake..Waker$RP$$GT$$GT$$GT$$GT$17h4e207d90019cfe5eE" (@name "_ZN4core3ptr191drop_in_place$LT$std..sync..poison..PoisonError$LT$std..sync..mutex..MutexGuard$LT$alloc..vec..Vec$LT$$LP$spin_sdk..wit..wasi..io..poll..Pollable$C$core..task..wake..Waker$RP$$GT$$GT$$GT$$GT$17h4e207d90019cfe5eE") (;67;) (type 1) (param i32)

This results in wasm-tools validate failing with the following error message:

I've also noticed how sometimes a component can be assigned a name after a roundtrip.
For example:
(component
  (core module $A (;0;)
    (type (;0;) (func (result i32)))
    (func (;0;) (type 0) (result i32)
      i32.const 1
    )
    (export "one" (func 0))
  )
  (core module $B (;1;)
    (type (;0;) (func (result i32)))
    (import "a" "one" (func (;0;) (type 0)))
  )
  (core instance $a (;0;) (instantiate $A))
  (core instance $b (;1;) (instantiate $B
      (with "a" (instance $a))
    )
  )
)

Becomes:
(component $B
  (core module $A (;0;)
    (type (;0;) (func (result i32)))
    (func (;0;) (type 0) (result i32)
      i32.const 1
    )
    (export "one" (func 0))
  )
  (core module $B (;1;)
    (type (;0;) (func (result i32)))
    (import "a" "one" (func (;0;) (type 0)))
  )
  (core instance $a (;0;) (instantiate $A))
  (core instance $b (;1;) (instantiate $B
      (with "a" (instance $a))
    )
  )
)

adding a $B to the component
Is this intended?

In-repo there's no round-tripping of components from wasmparser to wasm-encoder so I'm unfortunately not sure how to reproduce this or narrow in on what you're talking about. In the abstract, no, a roundtrip shouldn't change names. That being said I don't know what code in this repository would be culprit given the lack of support right now.

I've tried debugging this by moving the function that was causing this issue to a smaller .wat file but it surprisingly works fine there.
I found that at this location is where something of the type "#func67  can be written and put a break point there but interestingly it is never called.
I also checked how the aforementioned function is written and it goes into this branch which I believe should cause it to be normal and not start with "#func67 . Do you have any advice on how to further debug this?

Are you perhaps working with multiple versions of wasmprinter? For example one with a wasm-tools CLI and a different one as a Rust dependency? These syntaxes look a little different along the lines of recent-ish changes made to wasmprinter, but that would require having multiple versions in play.

In the screenshot above though it looks like you're using wasm-tools validate? It looks like that version of wasm-tools may not have support for $"foo" identifiers which the input file is using.

Apologies, did not realise that! There does seem to be a different name issue now. It looks like wasm-tools validate cannot find a function that is in the same module.

Are you sure those are in the same module? A component can have multiple core modules within it and these two statements look like they might be in different core wasm modules if they're similar to what wasm-tools component new produces.

Yup I'm sure! I've manually verified it. There are multiple core modules in this component but both the function declaration and the export are in core module (;2;). In this module, there are 34 functions defined and the function is in a (table (;0;) 34 34 funcref). The binary is huge but in case you would want to look at it, it's here.

In that file the export on line 72302 is entirely unrelated to the core wasm module defined on line 2. The export is within the component meaning the component doesn't have the function in question of that name.
To clarify it's quite difficult to help with these sorts of questions where only very small snippets of things are pasted here and there and there's no reproduction step with wasm-tools. Is this an issue with the production of *.wat in the first place? Is this an issue with wasmprinter producing the *.wat file from a valid binary?

It does look like updating the wasm-tools and solving another bug fixed it. Apologies for all the inconvenience caused.


Adds passive/once to EventListenerOptions type

Fixes #325.
Despite this supposedly being in TypeScirpt (https://github.com/Microsoft/TypeScript/issues/9548), it's not, so we augment the type here.
Also adds tests for once and passive options.

The options are defined on the AddEventListenerOptions interface, not EventListenerOptions.
See: https://github.com/Polymer/lit-element/pull/326


[Watson][98a3f67d-e3ee-e2b9-f062-ca8626cbbf77]IN_PAGE_ERROR_c0000006_PresentationCore.dll! Module..cctor

Generated issue from Watson
Watson Link:  https://watsonportal.microsoft.com/Failure?FailureSearchText=98a3f67d-e3ee-e2b9-f062-ca8626cbbf77
ADO Link: https://microsoft.visualstudio.com/DefaultCollection/OS/_workitems#id=27476553&triage=true&fullScreen=true&_a=edit
Process: powerlauncher.exe,
Module: presentationcore.dll

Moving out based on low hit count:

1
0.18 %

No hits after 22.1.0


go/token: FileSet grows without bound

Background: A token.FileSet holds a collection of non-overlapping token.Files and provides a mapping from token.Pos integers to position information (file/line/column/offset). This is analogous to the way an address space containing several non-overlapping file mappings defines the meaning of a numeric pointer value. Applications that parse Go files are expected to use a single FileSet to provide meaning to all the token.Pos values in all the ASTs; in this way, the AST nodes themselves needn't include a pointer to the mapping information, as it can be implicitly supplied by the contextual FileSet.
The problem: this design leads applications to create a single FileSet that is effectively a ubiquitous global variable. A long-running application may encounter and parse an unbounded stream of files, calling AddFile for each one, causing its set of Files to grow without bound. The FileSet retains each File indefinitely, even after the application no longer cares about it. The memory footprint of a File is approximately one int per line of the file. Go source files in the standard library have an average of 371 lines, leading to 3KB of wasted space per file. Our application (gopls) parses a file at least once per keystroke of a Go developer's editor.
I can think of a few ways the memory usage of FileSet could be reduced.
The first approach is to move away from the concept of a single central FileSet in an application. Instead one would create a new FileSet for every parse, so that FileSets and Files are typically in 1:1 correspondence. An application could, as needed, create transient FileSets containing only the small subset of existing Files necessary for a given operation, such as invoking the type checker. However, this would still require all those Files to be non-overlapping, which requires central management of the "next free address" variable (like sbrk(2) in the mmap analogy) that should be provided in each call to FileSet.AddFile(base). It would also require that every call to Parse go through this central management, which might be practical within an application but doesn't seem feasible if libraries with published APIs are considered.
A second approach would be for the parser to save the token.File in every node of the AST so that there is never any need to maintain or consult an external FileSet data structure: each AST node's (*File, Pos) information would be complete. This approach however requires that every place that today uses a token.Pos to refer to a file position (relative to some implied FileSet) would need to be changed to a (*File, Pos) pair. For example, in errors from the type checker, and in diagnostics from the analysis framework. This seems like a major incompatible change to existing libraries.
The third, and simplest, approach, is to add a (*FileSet).RemoveFile(*File) method that removes a File from the set so that subsequent queries such as Pos, File, and Iterate return a negative result---like munmap in the mmap analogy. The liberated portion of the address space would not be re-used, but the File's memory could be reclaimed. As with munmap, an application would be responsible for remembering to call RemoveFile at an appropriate time, and not too soon. I propose we take this approach. The change to FileSet is very simple and low-risk.
@findleyr @griesemer

A fourth approach (a variant on the first): FileSet.Base is replaced by an actual global variable in the token package, shared by all FileSets; the base value provided to FileSet.AddFile is ignored. This ensures that all token.Files are inherently non-overlapping, permitting any subset of them to be collected in a transient FileSet. In other words, any collection of FileSets would be consistent in their positive Pos->Position mappings, even if they represent different subsets of files.
In theory, a downside of this approach is that the global counter would grow faster than each individual FileSet.Base, but (a) in practice there is only one FileSet in the application (see above!), and (b) even if that were not the case, we would still be in no danger of overflowing an int---not on a 64-bit machine at least.

My understanding is that we are worried ... exhausting the available Pos values.

Your analysis is correct but, no, I'm not at all worried about running out of address space. No-one has ever worked at 200 keystrokes/minute for 16 hours straight, and I'm pretty sure gopls would crash at least once if they tried. It also needs more than 2GB of RAM for most workloads, and no laptop is a 32-bit machine.
What I'm worried about is actual memory consumed by the newline index tables.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It does seem like there are many many parts of the go/* packages that assume batch mode and are stressed near breaking by interactive use.

That's definitely  true, but I think we should decouple this proposal from larger changes. It will be a long time before we can stop using token.FileSet in gopls, and yet this unavoidable memory leak has very real consequences for our users today. (Consider that, while working on a large file with ~10k lines, gopls can leak 100kb per keystroke).

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group


Add login support for instructor

Motivation
Login for instructor is not supported yet.
Possible Steps

In the intialize.py file check if the user is an instructor or student and disable student only commands for the instructor.
Firebase temp data is given in Schema/ directory, so please check them out!

Hi @real-Vansh-Khare
I am interested in doing this issue
please assign me this!!