Report rewrite as stuck when term index is none

Closes #457
When a term's index is None, the terms is stuck.
Previously, rewriteStep threw an exception when a term's index was None, causing an RewriteAborted result to be returned by performRewrite, leading to Aborted execute response.

Subsumed by https://github.com/runtimeverification/hs-backend-booster/pull/465


chicago-taxi

Rework the current chicago-taxi solution. There are dependency conflicts with the current implementation on AI Platform. May need to upgrade the runtime, keras version, and deployment strategy.

@truongc2 and @bobbyjacob anyone looking at this?

I pushed the chicago-taxi demo that I got working for the GCP MLOPs assessment to a new branch in this repo: gcp_ml_assessment_chicago_taxi.
That demo works, but only in the jupyter notebook on vertex-ai workbench that I got working for the assessment:python-20220624-164215-bjacob.
If I try to clone the repo to another workbench instance, the demo breaks due to python dependency issues. The new notebook has a different set of default installed packages. I tried creating conda and venv versions of the working notebook environment but can't get it working on another instance.

I pushed a new branch gcp_ml_assessment_chicago_taxi_aaa. In a new workbench environment, I ran these commands:
pip install tensorflow==2.8.4
pip install tensorflow_data_validation==1.8.0
pip install tensorflow_transform==1.8.0
pip cloudml-hypertune

This notebook works completes without error: 01-dataset-management.ipynb.
This one fails with
CustomJob projects/354621994428/locations/us-central1/customJobs/2464840774366265344 current state:
JobState.JOB_STATE_RUNNING
CustomJob projects/354621994428/locations/us-central1/customJobs/2464840774366265344 current state:
JobState.JOB_STATE_RUNNING
CustomJob projects/354621994428/locations/us-central1/customJobs/2464840774366265344 current state:
JobState.JOB_STATE_FAILED

"The replica workerpool0-0 exited with a non-zero status of 1.
Traceback (most recent call last):
  File \"/opt/conda/lib/python3.7/runpy.py\", line 193, in _run_module_as_main
    \"__main__\", mod_spec)
  File \"/opt/conda/lib/python3.7/runpy.py\", line 85, in _run_code
    exec(code, run_globals)
  File \"/root/.local/lib/python3.7/site-packages/src/model_training/task.py\", line 27, in <module>
    from src.model_training import defaults, trainer, exporter
  File \"/root/.local/lib/python3.7/site-packages/src/model_training/trainer.py\", line 18, in <module>
    import tensorflow_transform as tft
  File \"/opt/conda/lib/python3.7/site-packages/tensorflow_transform/__init__.py\", line 19, in <module>
    from tensorflow_transform.analyzers import *
  File \"/opt/conda/lib/python3.7/site-packages/tensorflow_transform/analyzers.py\", line 39, in <module>
    from tensorflow_transform import analyzer_nodes
  File \"/opt/conda/lib/python3.7/site-packages/tensorflow_transform/analyzer_nodes.py\", line 36, in <module>
    from tensorflow_transform import nodes
  File \"/opt/conda/lib/python3.7/site-packages/tensorflow_transform/nodes.py\", line 33, in <module>
    from future.utils import with_metaclass
    ModuleNotFoundError: No module named \'future\'

To find out more about why your job exited please check the logs: https://console.cloud.google.com/logs/viewer?project=354621994428&resource=ml_job%2Fjob_id%2F2464840774366265344&advancedFilter=resource.type%3D%22ml_job%22%0Aresource.labels.job_id%3D%222464840774366265344%22"


Typescript type annotations as comments

Typescript’s goal is simply be Javascript + Types.
There are many use cases where one might want to use the excellent typechecker but not really have any emit stage.
Projects already written in javascript work with allowJS. Typescript already supports parsing types from jsdoc comments.
What would be really awesome is just comment annotating your javascript with types and the project gets the benefit of being type checked.  This could be a boon for a lot of existing javascript projects. Getting intellisense, VSCode typechecking on the fly and a lot of language server awesomeness.
e.g.
/// <reference path="..." />

class Hello {
    /*:: private*/ hello(message /*: string*/) /*: Promise<{}>*/{
                const promise /*: Promise<void>*/ = null
        return /*:: <Promise<{}>>*/ null;
    }
}

i.e
/: [type] */
/:: [tscode] */

https://flowtype.org/blog/2015/02/20/Flow-Comments.html
Flow has a descent spec. It was a major feature request on their end too.
I think the big value add is typescript's language service. Being able to annotate an existing js code base and get on the fly error checking + code completion is pure awesomeness.
No source mapping needed, Browser/node reads the same code. Don't need to wait for a transpiling step. Node_modules written in this flavor don't need a separate typings install since source+types is same file.

+1 I really love this aspect of flow and wish that TS supports something similar.

I haven't used it myself, but since 2.0, TypeScript supports jsdoc for typedef: JSDoc support in JavaScript

In my view, the difference is that the JSDoc approach does not resemble the standard TS approach.  Take the example in the tutorial: http://www.typescriptlang.org/docs/tutorial.html
function greeter(person) {
    return "Hello, " + person;
}

The recommended TS according to the docs:
function greeter(person: string) {
    return "Hello, " + person;
}

The comment-based approach that flow supports really resembles what you would write -- the type annotation is basically wrapped in a C-style comment:
function greeter(person/*: string*/) {
    return "Hello, " + person;
}

The JSDoc approach technically supports this case, but it is very different from the canonical TS approach:
/**
 * @param {string}  person
 */
function greeter(person){
    return "Hello, " + person;
}

You are correct. Jsdoc has a lot more verbosity than flow style comments.
On Wednesday, December 14, 2016, pardonmyenglish<EMAIL_ADDRESS>wrote:

In my view, the difference is that the JSDoc approach does not resemble
the standard TS approach. Take the example in the tutorial:
http://www.typescriptlang.org/docs/tutorial.html
function greeter(person) {
return "Hello, " + person;
}
The recommended TS according to the docs:
function greeter(person: string) {
return "Hello, " + person;
}
The comment-based approach that flow supports really resembles what you
would write -- the type annotation is basically wrapped in a C-style
comment:
function greeter(person/: string/) {
return "Hello, " + person;
}
The JSDoc approach technically supports this case, but it is very
different from the canonical TS approach:
/** * @param {string}  person   */function greeter(person){
return "Hello, " + person;
}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-267244539,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVH1GfPO_GWAXT_fmBeb4qedUwNqJks5rINRcgaJpZM4JLxhT
.

It seems there is often resistance to adding a build step in projects where previously was none - at my workplace I am using Flow to provide static analysis over Typescript precisely because of this, and the amount of community support this feature has in Flow suggests this scenario is reasonably common.
If Typescript supported annotations in comments I believe it would pick up a lot of this use, as it's generally considered on the whole to be more powerful than Flow. I know I'd rather use it.
This also shouldn't be specific to Salsa (I guess), my dream implementation of this feature would be that tsc or a ts language service in my IDE of choice would just load .js files with TS comments and treat them as if they were typescript.

Totally agree with this.
JS with typed comments definitely makes js more powerful.
On Mon, Jan 9, 2017 at 9:23 PM Jarrad Whitaker<EMAIL_ADDRESS>wrote:

It seems there is often resistance to adding a build step in projects
where previously was none - at my workplace I am using Flow to provide
static analysis over Typescript precisely because of this, and the amount
of community support this feature has in Flow suggests this scenario is
reasonably common.
If Typescript supported annotations in comments I believe it would pick up
a lot of this use, as it's generally considered on the whole to be more
powerful than Flow. I know I'd rather use it.
This also shouldn't be specific to Salsa (I guess), my dream
implementation of this feature would be that tsc or a ts language service
in my IDE of choice would just load .js files with TS comments and treat
them as if they were typescript.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-271489470,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVH482DM1OpASNYEEGF-gmH_-XD2_ks5rQxXcgaJpZM4JLxhT
.

First shot at implementing this. It currently only looks at .ts files (pretty useless, we need it to work with .js). It may also benefit from some equivalent of //@flow, otherwise ts is likely to go parsing everything it can find in node_modules. However, the basic functionality is there and working.

IMHO, I think this feature is not very necessary (and this is also for future readers who would were eagerly looking for this feature).
At the beginning, I was also shy to add a compilation step in our projects, and considered using Flow only for the benefit of comment syntax. But a few tries whith ts, I realized that :

the compilation step in Typescript is quite fast, simple and reliable
the js code generate is very readable. Actually, the code transpiled by Typescript is nearly the same that i would have written ! (minus some line breaks removed, etc...). It means that if you want, at any moment, you could stop using ts, and revert back to the js files.

You juste have to rename .js file to .ts file in order to have type checking.
FWIW, our project is a very complex application developped with node and extjs, and we migrate nearly 60% of server code to Typescript in 2 weeks.

Thanks for your feedback Arnaud.
This is a very polarizing discussion.
I'll list some arguments I have experienced and got from friends at other
companies.
Argument 1: From the fundamentals Isn't Typescript just javascript +
types?  If so, then one would expect their javascript to remain as is and
just add types in their js code. All major browsers and node support es6 in
their latest version. Having plain js works. Transpilation is overkill.
Node modules could benefit from it. JS libraries could benefit. It's only
when you're stitching code that webpack is needed.  With http2 push
https://en.m.wikipedia.org/wiki/HTTP/2_Server_Push even stiching into one
big js isn't needed.
Argument 2: vscode js experience that uses the tsserver gives a very
handicapped experience for js compared to ts. If js is the lingua franca of
the Web then it makes sense to give javascript the nice experience.
Jsdoc/closure comments/flow comments are all efforts to make js powerful.
Argument 3: Dealing with sourcemaps is a PITA. Because of the reverse
mapping step, the stars need to align for debuggers to get everything
right. I've given up many times finding the exact setup and simply moved to
just debug the generated js. Many tools do a half arsed Job with
sourcemaps.  See: https://github.com/Microsoft/vscode/issues/18363
⋅⋅⋅
Found the issue. Well, found a fix. The issue is that no one understands
sourcemaps. Neither do we nor anyone who develops libraries for sourcemaps.
⋅⋅⋅
Argument 4: Browser devtools have a great feature of live edit.
A class of problems go away if source is what the engines run. Testing
iterations with live edit is instantaneous. A transpile step breaks the dev
loop. Can't copy a ts function into console to test something quick.
Browsers barf at the type syntax. JS exceptions don't map to the source. We
have to do that manually.
In a way what we really need is browsers and node to run javascript with
type hints. Python does that by ignoring the type hints
https://www.python.org/dev/peps/pep-0484/. May be Ecma will someday approve
of type syntax. JS engines will do the correct thing with types. Until
then, a commented syntax would be handy. A great js editing experience
would increase developer productivity.
On Thu, Jan 12, 2017 at 6:08 AM Arnaud Benhamdine<EMAIL_ADDRESS>wrote:

IMHO, I think this feature is not very necessary (and this is also for
future readers who would were eagerly looking for this feature).
At the beginning, I was also shy to add a compilation step in our
projects, and considered using Flow only for the benefit of comment syntax.
But a few tries whith ts, I realized that :

the compilation step in Typescript is quite fast, simple and reliable

the js code generate is very readable. Actually, the code transpiled
by Typescript is nearly the same that i would have written ! (minus some
line breaks removed, etc...). It means that if you want, at any moment, you
could stop using ts, and revert back to the js files.

You juste have to rename .js file to .ts file in order to have type
checking.
FWIW, our project is a very complex application developped with node and
extjs, and we migrate nearly 60% of server code to Typescript in 2 weeks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-272171576,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVIjPMSnz__hbsnZROGzIpcjJbrrMks5rRjPTgaJpZM4JLxhT
.

Thx for you detailled answer !
I have to admit your arguments are quite valid, and probably my feedback too brief (mainly because I'm not a native english speaker).
My feedback is more  "hey, you can jump into ts without syntax comment, you should not choose beetween TS and Flow just basing your decision upon the existence of this syntax in Flow".
Because it was exactly the situation where we were two months ago.
Concerning sourcemap, so far, we didn't have too much problems in VSCode. For instance, node debugging has always run perfectly (while again : it's a very complex project). And in case of error in prod, it's not so too difficult to map the .js line to the .ts line (even if it's indeed a waste of time).
However, we have only migrated server code to ts, we don't consider migrate browser code at the moment.
An other caveat is indeed the use of VS Code for editing  .js files : we used to be on ST3 for js files, and VS Code is less fast and convenient than  ST is.
However, VS Code is evolving quickly, and in the right direction IMO.

Then there will be two type syntaxes embedded in comments, actually three if you include Flow types. JSDoc already has multiple interpretations. Throw TypeScript types into comments and even more complexity is introduced.

Want to clarify. I don't think commented types in Typescript bring much
benefit. As you said it just introduces complexity.
Commented types in javascript (.JS)  are useful. In that scenario, there
are only two types. Jsdoc and flow.
Flow types are just Typescript types wrapped in comments.
E.g /:string/ and /::/(someValue)
This means having a tsconfig with allowJs should give a very close
experience to Typescript. Both type checker and vscode ide.
On Fri, Jan 13, 2017 at 12:17 AM Aluan Haddad<EMAIL_ADDRESS>wrote:

Then there will be two type syntaxes embedded in comments, actually three
if you include Flow types. JSDoc already has multiple interpretations.
Throw TypeScript types into comments and even more complexity is introduced.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-272385951,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVOwvwdI_N1Y2UeK7PcF1LuMp0PFdks5rRzMRgaJpZM4JLxhT
.

Want to clarify. I don't think commented types in Typescript bring much

Thanks I wasn't sure if this was intended to apply to JavaScript and TypeScript or just JavaScript.

Commented types in javascript (.JS)  are useful. In that scenario, there
are only two types. Jsdoc and flow.

Perhaps but there are different interpretations of JSDoc, TypeScript is one interpretation, Closure is another, JSDoc v3 is yet another.

Flow types are just Typescript types wrapped in comments.
E.g /:string/ and /::/(someValue)

I so wish that were true. Unfortunately the syntax is subtly different. More significantly the meaning can be radically different.

This means having a tsconfig with allowJs should give a very close
experience to Typescript. Both type checker and vscode ide.

That would be a great indeed.

@aluanhaddad Could you provide some examples of the differences between the three styles?

Flow:
type T = { name: string }
Array<U: T>

TypeScript:
type T = { name: string }
Array<U extends T>

JSDoc:
@template T
Array<T>

The difference in interpretation is more what I'm concerned about.

That last example is not yet supported by closure and I'm not even sure if that's how you would write it it's hypothetical syntax

@aluanhaddad I think you are confused about the proposal.  The idea isn't to introduce the exact flow syntax into typescript, but rather to introduce a special comment form which JS engines ignore but tsc and typescript parsers interpret as valid TS code.
I gave an example in https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-267244539 but it wasn't that clear so I will try another example from the tutorial.
Let's say you have an existing JS codebase:
function greeter(person) {
    return "Hello, " + person.firstName + " " + person.lastName;
}

var user = { firstName: "Jane", lastName: "User" };

document.body.innerHTML = greeter(user);

The TS form that defines the person interface looks like:
interface Person {
    firstName: string;
    lastName: string;
}

function greeter(person: Person) {
    return "Hello, " + person.firstName + " " + person.lastName;
}

var user = { firstName: "Jane", lastName: "User" };

document.body.innerHTML = greeter(user);

The comment form which we are discussing is a series of comments atop the JS form that aligns with the TS form:
/*::
interface Person { // <-- this is the same exact code you would write if you fully bought into TS
    firstName: string;
    lastName: string;
}
*/
function greeter(person/*: Person*/) { // <-- the type annotation is in a C-style comment that JS ignores but TS would parse
    return "Hello, " + person.firstName + " " + person.lastName;
}

var user = { firstName: "Jane", lastName: "User" };

document.body.innerHTML = greeter(user);

The ability to write snippets of typescript and embed them in comments would enable developers to slowly annotate their JS code without changing their minified JS output and without having to buy into TS from the onset.  This is important for adoption.  We ended up adopting flow for a 50kloc JS project because it was incredibly easy to demonstrate the power of flow and incremental type annotations without actually changing the existing workflows or existing live JS.

I am sorry, I am not trying to be stubborn. I do understand the use case and I agree it is both valid and valuable. I am talking about the way tools behave. If a tool uses a heuristic to find Flow types in comments, it could choke on this. The same is true for JSDoc, but this is probably easier to disambiguate.

@aluanhaddad a heuristic to pick up flow types would benefit unlikely to pick up these hypothetical typescript types by mistake - flow-annotated-js needs to contain a // @flow comment to trigger processing.

Agree with @pardonmyenglish. Typescript doesn't need to understand every
syntax out there. It just needs to enable a typechecking scenario for
javascript files.
With this Tsserver can support  the magic of refactoring, code completion,
etc for Javascript files
On Sat, Jan 14, 2017 at 5:25 PM Jarrad Whitaker<EMAIL_ADDRESS>wrote:

@aluanhaddad https://github.com/aluanhaddad a heuristic to pick up flow
types would benefit unlikely to pick up these hypothetical typescript types
by mistake - flow-annotated-js needs to contain a // @flow comment to
trigger processing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-272666510,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVGS43w9vnxsUXLvV0-ZGkgOToPkAks5rSXWJgaJpZM4JLxhT
.

And in case of error in prod, it's not so too difficult to map the .js line to the .ts line (even if it's indeed a waste of time).
For the future reader : I correct myself, with https://github.com/evanw/node-source-map-support, we can have the line number in the .ts file, and it works perfectly for us.

Any updates on this?
Is there a way to implement this as a plugin or something? I'm thinking of just pushing the source code through something like this:
return source
  .replace(/\/\*::([\s\S]*?)\*\//g, '$1')
  .replace(/\/\*:(.*?)\*\//g, ':$1');

and then passing that to TS, but I'm primarily focused on VS Code support

I do like function syntax e.g
function hello(greeting /*: string*/, notify /*:boolean*/) {
}

Rather than jsdoc comments which are verbose and require duplication of param name.
Currently not supported but I feel that it should be pretty easy to add.
https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript

any update on this?
support for this would greatly reduce the hurdle for JS devs to get started with typescript while being not so verbose and awkward to write as jsdoc comments

I have been told on multiple occasions that TS team is not willing to take on this feature. It introduces another syntax which is another path of syntax the TS team will need to maintain.
@mhegazy could probably elaborate on this.
I personally find jsdoc syntax too verbose to use it.
What I would love to see is the tc39 committee actually bringing type hints to actual js parsing spec. Close to how python does it with https://www.python.org/dev/peps/pep-0484/.
That means I can just write javascript with types and interfaces. No weird comment syntax. The JS engines will just ignore the type hints like how babel typescript preset does its thing.

@nojvek I agree having types and interfaces ignored by the js parser would be the best, but I guess that will not happen (if ever) very soon.. =/

Dear core typescript developers, thank you for  such a high quality tool you made.
But if you only could imagine how we, typescript users, desperately need the feature discussed...
You've done so much and what's left is so little.

It is possible with some hacks:
var ts = require("typescript");

var fileNames = [
  'myfiles.js'
];

var options = {
  allowJs: true,
  checkJs: true,
  noEmitForJsFiles: false,
  target: ts.ScriptTarget.ES2017,
  noEmit: true, // don't write compiled files
  allowNonTsExtensions: true,
  moduleResolution: ts.ModuleResolutionKind.NodeJs,
  module: ts.ModuleKind.ES2015
};

// patch ts.createSourceFile to convert flow-style comments in .js files
var createSourceFileOrig = ts.createSourceFile;
ts.createSourceFile = (fileName, text, languageVersion, setParentNodes) => {
  if (fileName.match(/\.js$/)) {
    text = text.replace(/\/\*::([\s\S]+?)\*\//gm, '$1');
    text = text.replace(/\/\*:(.+?)\*\//gm, ':$1');
  }
  return createSourceFileOrig(fileName, text, languageVersion, setParentNodes);
}

// make typescript thing that .js files are same as .ts
//   (otherwise it will validate them as js files)
var ensureScriptKindOrig = ts.ensureScriptKind;
ts.ensureScriptKind = (fileName, scriptKind) => {
  var ext = fileName.substr(fileName.lastIndexOf("."));
  return ext == '.js' ? 3 : ensureScriptKindOrig(fileName, scriptKind);
};

// run and print results
let program = ts.createProgram(fileNames, options);

let emitResult = program.emit();
let allDiagnostics = ts.getPreEmitDiagnostics(program).concat(emitResult.diagnostics);

allDiagnostics.forEach(diagnostic => {
    if (diagnostic.file) {
        let res = diagnostic.file.getLineAndCharacterOfPosition(diagnostic.start);
        let line = res.line, character = res.character;
        let message = ts.flattenDiagnosticMessageText(diagnostic.messageText, '\n');
        console.log(`${diagnostic.file.fileName} (${line + 1},${character + 1}): ${message}`);
    } else {
        console.log(`${ts.flattenDiagnosticMessageText(diagnostic.messageText, '\n')}`);
    }
});

@Paxa nowadays we actually parse and check jsdoc-style type annotations in js (which I'd recommend over jamming ts-in-comments into a js file):
// @ts-check
/**
 * @type {function(number): undefined}
 */
const x = x => void 0;
x("ohno"); // will error

so there's a builtin syntax available to add type annotations in JS - we just wanted to support what already had a rather broad community, rather than introducing a new style of semantic comments for no reason other than not really liking the style of the other (which is what a lot of the more recent comments in this thread are gripes about).

Jsdoc types in js is very fragmented though. 90% of the time vscode gets
the wrong type. We can’t import .d.ts types in js files like TS can.
TS has a lot of strictness when you declare a certain type. Jsdoc seems to
silently fail.
I did submit a TS -> jsdoc equivalent PR a while back but it never made it.
As someone that loves JS but also loves Typescript vscode autocomplete +
checking/refactor abilities, having a guarantee that every Typescript
feature has a jsdoc equivalent is a massive boon.

Jsdoc types in js is very fragmented though. 90% of the time vscode gets
the wrong type. We can’t import .d.ts types in js files like TS can.

Actually with 2.9 (which should have an RC cut soon, if not already) you can.
/** @typedef {import("some-declaration-file-module").Foo} Foo */

TS has a lot of strictness when you declare a certain type. Jsdoc seems to
silently fail.

Please elaborate - we're trying to find and fix any holes like this.

Thanks @weswigham I think it depends on personal syntax preferences. I like compact syntax more. Currently I find it more comfortable to convert project slowly, file by file and add type annotations only when necessary.

@weswigham here's a philosophical take on Typescript.  Its a great language and does amazing things, but its not Javascript. You can't copy paste and run it on a console, or let the browser/node run it directly. It needs to be transpiled in some way. Javascript is the lingua franca of the web and will remain so for a while. What is lacking in javascript is a great input/output contract for functions, modules and classes. Kind of like a C/C++ .h header files. That's how I see .d.ts files in npm packages and @types org. At the root I believe a big fundamental need is: A specification of a contract for js libs.

Jsdoc is great, but strict jsdoc would be awesome. If I have // @ts-check, no types should slip through. Unresolved types should error. Vscode gives excellent code completion on jsdoc and shows squigglies if something is not valid. (not sure if something changed recently, but jsdoc types seemed loose when I last played with it)

Import multiple types like /* @import {X, Y, Z} from './hello.d.ts' */. /** @typedef syntax is a step down from excellent "import only what you need" philosphy of ES6.

Being able to define a module types contract in .d.ts file and ensure corresponding JS is compliant to it. Kind of like /* @implements SomeInterface */ for modules and classes.

Automatically build .d.ts files with --emitDeclarationsOnly from combination of  js files and .d.ts files. Puppeteer and other projects have been wanting this for a long time. It doesn't make sense to hand maintain npm types .d.ts files if they can be generated from jsdoc.

Basically, if typescript ships with a solid JS typechecker and .d.ts generator story, the way most JS projects are written fundamentally changes. Rather than a .d.ts being an after thought in npm @types, more projects see value in just making it part of the project since its easy. More projects adopt typechecking since its not disruptive.

Was getting all ready to fire up a response and found @nojvek had already written nearly everything I wanted to write.
Getting the basics of typescript checking supported with JSDoc is great, and it's really cool to see what the team has achieved so far. However, the long tail of less common features is still (and always will be) a problem. Off the top of my head, I cannot write in JSDoc:

function overrides
interface inheritance
generic parameter defaults
new() interface magic key

Keeping JSDoc support up to date with typescript features is a big maintenance burden to ask of the team, and tbh any jsdoc syntax that allows the above is going to be non-standard and ugly af anyway.
The d.ts concerns that nojvek raise are huge in my experiences as well, not gonna retype it because he wrote it perfectly.

I have a suggestion, which might not be too popular. How about allowing definitions in comments, but only if they match the format of a d.ts file? In other words, we simply inline the d.ts file.
/*@ts
interface Person {
    firstName: string;
    lastName: string;
}
*/

/*@ts function greeter(person: Person): string; */
function greeter(person) {
    return "Hello, " + person.firstName + " " + person.lastName;
}

Advantages:

No new syntax to learn
No new syntax to parse (apart from detecting the comments)
Types can easily be moved to or from a d.ts file

Disadvantages:

Some repetition of function and argument names.
A little bloat

@joeytwiddle that was already proposed in this issue itself e.g.
https://github.com/Microsoft/TypeScript/issues/9694#issuecomment-272664643

Yeah the hardest part is really convincing Typescript team (cc @DanielRosenwasser) that this is a good idea. TS is essentially a superset of JS, so technically this should be quite straightforward to implement it such that the superset-ness of TS is literally just comments in a JS file.

The inability to gradually introduce proper TypeScript annotations into existing JavaScript modules without having to add a compile step for each and every one, is pretty much the only thing holding me and my team back from switching from Flow to TypeScript.
A comment-based annotation option (in .js files flagged with // @ts-check) also dramatically lowers the threshold for developers to do "drive-by-guerrilla-typing" on older projects and smaller modules.

I just found myself in a similar situation as @TomasHubelbauer did.
I need to use more advanced concepts like mapped types or conditional types but I can't figure out a way to define the aforementioned concepts using JSDoc.
I'm currently working on a project that doesn't use TS but I'd love to get some type checking in VSCode based on type annotations in comments.
Adding support for type annotations in comments would be beneficial for people who would like to get the benefits of TS but the decision about the techs used in the project is not made by them.

For situations where you need a more advanced type that isn't supported in JSDoc, you can declare the types in a .d.ts file and then reference the types back in the JSDoc.

For anyone coming here looking to add TypeScript type-annotations within comments, I've made a fork with a hack to allow exactly that:
https://github.com/luciotato/plus-typescript/blob/master/README.md
https://github.com/luciotato/plus-typescript
@kdmadej @TomasHubelbauer @maranomynet @nojvek @joeytwiddle Maintainers are welcomed

Holy moly. This is incredibly cool @luciotato . What I love about this is it supports full breadth of TS syntax. The current jsdoc annotations that typescript team recommends is really a hodge podge of quirks. I've invested 6 months of my life converting our existing js to jsdoc only to realize there are so many little things missing.

@DanielRosenwasser

For situations where you need a more advanced type...

This is about 2 minutes into trying to define types. I basically have no code that does not use Generics... It becomes a really expensive problem once you realize that 50% of the code needs to be in the .d.ts file. Not only that, but trying to memorize two different syntax is not good for productivity.

Like others who joined late to the party, let me start by saying how much I appreciate the effort that's gone into Typescript. It's an incredible tool, and to be commenting at all on an issue is a testament to that.
The nearly 6 years this issue has been open is a bit discouraging. The use cases and value have been established, @luciotato built a working prototype, and Flow has long supported this, so there are real users of this feature in the wild. Part of what "opt-in types" ought to mean is that you can start using types in a project that's not ready to be converted to Typescript, even if that conversion is rightly considered easy. The value of writing new libraries in TS is limited by the inability to fully exploit the value of those types in vanilla JS consuming code (and I say "fully exploit" to deliberately cover what one cannot accomplish by telling the editor to treat JS files like typescript and other ways of seeing the types of 3rd party libraries in a vacuum, without defining types in the vanilla JS calling code).

There appears to be some movement on this!
https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/

Also: "We decided to lobby for TypeScript officially becoming JavaScript, but still pretend that's not what we're doing"
🤪

but considering there are browsers that haven't hit EOL that don't even support ES2015 (looking at you IE 11) I think this is a potential solution for 2030

Types can always be stripped away/"downleveled" for older browsers. Considering the proposal will take years of work if it does proceed, 2030 might be when you actually get the feature!

@DanielRosenwasser

Types can always be stripped away/"downleveled" for older browsers.
Stated differently, could we say "well you could still run your code through a typescript compiler to strip the types"? If so, this leaves us in the in the same position we're currently in, no?

I think one of the use case is:
Develop with your fancy new browser and develop faster without compile.
But in production you still use the transpiled/stripped/minified output even for some ie8 if you like/must.

Well if you're targeting Node, Deno, or primarily evergreen browsers, you can run as-is (especially for the development-time scenarios that @HolgerJeromin just mentioned). If you really need to accommodate older runtimes, you can add this as a production-time build step.

By the way, I have tried using JSDoc in a project, and I learned something I didn't know before:
We don't have to stick to the JSDoc way of declaring types, which usually involves lots of tags, and splitting up of objects.
We can instead use TypeScript types inside the JSDocs, to keep things smaller.
This is how we might expect to annotate a function using JSDoc
/**
 * @typedef {Object} MemberGroupsResponse
 * @property {Object.<string, MemberGroup>} memberGroups
 * @property {Object.<string, Array.<string>>} memberGroupsByUser
 *
 * @function getMemberGroupsUncached
 * @async
 * @param {string} month
 * @param {string} memberGroupsSheet
 * @returns {Promise.<MemberGroupsResponse>}
 */
async function getMemberGroupsUncached(month, memberGroupsSheet) { /* ... */ }

But actually we can annotate the function more simply, using a single TypeScript type!
/**
 * @type {(month: string, memberGroupSheet: string) => Promise<{
 *   memberGroups: Record<string, MemberGroup>;
 *   memberGroupsByUser: Record<string, string[]>;
 * }>}
 */
async function getMemberGroupsUncached(month, memberGroupsSheet) { /* ... */ }

Advantage:

This is much more concise!

Disadvantages:

This isn't really valid JSDoc, so this format isn't suitable for tools which only understand traditional JSDoc
Basically these annotations are only really useful in TypeScript-based development environments
No syntax highlighting for these TS-inside-JSDoc
In VSCode, autocomplete support works better for JSDoc than it does for this TS-inside-JSDoc
Still not as short as actual TypeScript. But it's certainly shorter than JSDoc!

So if you don't need traditional JSDocs but you would like some TS-checking in your JavaScript files, this hybrid approach might work for you.
(I am using TypeScript type checking in VSCode, with the option js/ts.implicitProjectConfig.checkJs but // @ts-check would also work.)

I'm trying to use tsc to generate .d.ts files for my fork of a JavaScript project, making minimal changes to the original .js files.  For almost everything tsc's inference is good enough, and for most of the rest adding comments as described by @joeytwiddle fills in the gaps.  But here's one that fails:
The original code:
delete Number.prototype.then;

Types that work in TypeScript:
interface MaybeThenable { then?: Function }
delete (Number.prototype as Number & MaybeThenable).then;

The same types in JSDoc annotation in a .js file:
/** @typedef { { then?: Function } } MaybeThenable */
/** @type { Number & MaybeThenable } */
var klass = Number.prototype;
delete klass.then;

Is rejected by tsc:
Type 'Number' is not assignable to type '{ then?: Function; } & number'.
  Type 'Number' is not assignable to type 'number'.
    'number' is a primitive, but 'Number' is a wrapper object. Prefer using 'number' when possible.

73             var klass = Number.prototype;
                   ~~~~~

It seems that tsc doesn't respect wrapper types given in TSDoc annotations

Turns out it works if I go to constructors, but it would be better if tsc handled types the same way in both TypeScript annotations and JSDoc annotations
/** @typedef { { prototype: Object & { then?: Function } } } MaybeThenableConstructor */
/** @type { NumberConstructor & MaybeThenableConstructor } */
var konstructor = Number
delete konstructor.prototype.then;


Allow to watch endpoints (using polling)

Related: https://github.com/dotansimha/graphql-code-generator/discussions/5580

I have a similar problem that would be solved by that too.
My server is being watched and once I change the schema file, it also starts rebuilding—and is therefore temporarily offline—so, when the codegen tries to reach the localhost endpoint, I get a ECONNREFUSED error. Either a pooling option or a timeout to ask for the watch to wait "X seconds" would work.

This would be great in particular for Hasura graphql-engine enums, which change if the contents of the underlying enum table change, but don't result in a change to the Hasura metadata files. For other changes, listening for changes to the metadata directory also does the trick.
Additionally, if using https://github.com/0no-co/gql.tada , you can also listen on the generated graphql .d.ts declarations since that tool supports polling on schemas.


webpack-dev-server missing in dev dependencies

Several package.json scripts are referring to the webpack-dev-server

@martinoss becuase this project was based on angular 2 webpack starter project, It was easier to do some copy paste for the dependencies and scripts. Needs some cleaning. Will look into this.

@martinoss we don't need webpack-dev-server. As we this is a .net project and webpack is running in .net process. We have to rely on webpack-dev-middleware which .net javascript services project offers. Also, I have removed reference of running dev server and creating dev and production builds using npm scripts as that is something handled by asp.net core javascript services package. Read more here.


Verifier policy : presentation-definition ,if order of credentials in request_credentials can pass.

Describe the bug
HI, now i try to Verifier with policy : presentation-definition
To Reproduce
i create verifier policy with
{
  "vp_policies": [
    "signature",
    "expired",
    "not-before",
    "presentation-definition"
  ],
  "vc_policies": [
    "signature",
    "expired",
    "not-before"
  ],
  "request_credentials": [
   {
      "format": "jwt_vc_json",
      "type": "BirthCertificate"
    },
   {
      "format": "jwt_vc_json",
      "type": "EducationalID"
    }
  ]
}

and use https://wallet.walt.id for present

Yes, it can verifier success.
by wallet order like this

But if i change order of request_credentials list ,with same credentials type
   "request_credentials": [
   {
      "format": "jwt_vc_json",
      "type": "EducationalID"
    },
   {
      "format": "jwt_vc_json",
      "type": "BirthCertificate"
    }
  ]

then, it not success to verifi

Question
My question is, why is it like this? And is the current situation right or wrong?
Thank you for your assistanc

Hello!
A fix for this is part of #861 . Please update your dependencies when it gets merged to main.
Thanks!


Refactor messages to use PennyNodes and instances

Currently we're at the point where a single message statement creates a single message box. Each one is completely self contained and fades in and out after creation and before destruction.

[x] First get it to where boxes function independently and are completely self contained
[ ] Reimplement maintaining a single text box control across all messages (while still using new system)
[ ] Become conscious of when the speaking object changes, and instance a new control for that only.
All of this is in preparation for implementing menus because they'll use a very similar system.

In order to complete step 3, MessageHandler will need to know ahead of time if it does or does not need to close, to ensure proper execution timing (not order).


Mesos 0.27.1, Kubernetes and Calico: inter-scheduler networking

This is a branch that joins together two branches (mesos and kube) of work done on calico integration. This branch uses mesos 0.26 compiled with netmodules, along with marathon .14, kubernetes 1.1.4 and calico 0.15.0 .
Kubernetes and Mesos tasks will be assigned an unique IP address from calico address pool, thus allowing tasks/containers running on different schedulers to exchange network traffic, as long as both tasks are running in the same Network security group (netgroup). Netgroups only allow network traffic between tasks that have at least one of their configured groups in common.
Currently, on mesos, only NON-DOCKERIZED marathon tasks support IP assignment (marathon's current limitation): https://github.com/mesosphere/marathon/blob/v0.14.0/docs/docs/ip-per-task.md
@matjohn2
@stevendborrelli
Tested on:

GCE

This is wunderbar! Thanks for bringing it all together in one place. Spinning this up now to take a look.

What is the status of this PR?

@anners About to be merged in.

Right, here's the new plan: to the best of my understanding this is blocked by a Calico bug. I'm going to start pulling this apart into little bits that we can merge into mainline so that master's k8s support can improve, even if everything else is still blocked.

Given the commit history, it looks like we'll have this smaller PRs (I've tried to order them but it may shake out differently):

dedicated kubernetes worker for all clouds
clean up "old" Kubernetes roles (commits like ca19c5dcbc841da19dfd1c10925839124df21baf)
update Kubernetes version to 1.2 (1.1 in this PR)
enable Kubernetes by default, only configured if worker present
enable calico by default.

And all on top of latest master.
Open questions:

@anners, @matjohn2: shall we continue to support Flannel until the Calico bug is fixed, or consider it completely blocking? (@zogg is off today, and we can get more details about it from him tomorrow.) This effects merge order of split PRs.
@zogg: can you explain all the logging stuff in eafef224d76efa915808c1183eb57407ef0969e4? Why is this included by default? Wouldn't it be better to use the ELK addon, if installed?

For later reference, I have currently cherry-picked all commits up to 1ea3ccc into feature/k8s-by-default.

@Zogg, I think it won't be possible to merge this pull request any soon because #863 got already reverted in #995, because of mesos/elasticsearch#457 which is a result of MESOS-4449. Is it possible to provide custom builds of mesos/elasticsearch docker image?

@jkramarz If you take a look at the commit history, 0.26 is changed to 0.27. I've updated the issue title accordingly!

@siddharthist, it's good to hear that!
According to https://github.com/projectcalico/calico-mesos-deployments/blob/master/docs/UsingCalicoMesos.md there will be a way to use it with Docker on Marathon, so I'm super-happy :-)

@Zogg @BrianHicks Is there a reason to keep this PR open? It seems that the only thing left on your list is integrate Calico, which is blocked.

@BrianHicks what is the bug in Calico that is blocking this PR?

@zogg :arrow_up:

@dbathgate https://issues.apache.org/jira/browse/MESOS-5061

Now that we've nailed down the Calico bug (can't seem to find where right now), what's the status of this PR?

Closing in favor of #1521


Update SkypeAppSDK.md

cc: @o365devx

Docs Build status updates of commit 36bcc7b:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Skype/AppSDK/SkypeAppSDK.md
:warning:Warning

Details

Skype/AppSDK/SkypeAppSDK.md

Line 2, Column 8: [Warning: duplicate-titles - See documentation] Title 'Skype for Business App SDK' is duplicated in: 'AppSDK/index.md(2,8), AppSDK/SkypeAppSDK.md(2,8)'. Titles must be unique within a docset.
Line 6, Column 1: [Warning: duplicate-h1s - See documentation] H1 'Skype for Business App SDK' is duplicated with other articles: 'AppSDK/index.md(7,1), AppSDK/SkypeAppSDK.md(6,1)'. First level headings must be unique within a docset.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@lindalu-MSFT can you please merge this PR?

Docs Build status updates of commit 52fe515:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Skype/AppSDK/SkypeAppSDK.md
:warning:Warning

Details

Skype/AppSDK/SkypeAppSDK.md

Line 2, Column 8: [Warning: duplicate-titles - See documentation] Title 'Skype for Business App SDK' is duplicated in: 'AppSDK/index.md(2,8), AppSDK/SkypeAppSDK.md(2,8)'. Titles must be unique within a docset.
Line 6, Column 1: [Warning: duplicate-h1s - See documentation] H1 'Skype for Business App SDK' is duplicated with other articles: 'AppSDK/index.md(7,1), AppSDK/SkypeAppSDK.md(6,1)'. First level headings must be unique within a docset.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Tooling for cryptography: a simple but effective approach?

I think security awareness is a big issue that has to be considered: I am not worrying about developers who are no security experts, but developers who are no security experts and who are neither aware of nor interested in that fact. This makes them not seeking any security tooling at all, and the best tool cannot do its job if no one seeks and thus, uses it.
What type of tooling are developers seeking, if they have no security awareness at all? They only seek the tooling they need to develop the features they want to develop. So the security tooling has to be already integrated into these and at the best, activated by default.
Concerning cryptography, a simple "informative warning" tool can be integrated into compilers or IDEs to foster security (and awareness): it remains an existing problem that base64 is assumed to be cryptography, and md5/sha1 remain in use for cryptographic purposes as well (just examples). A compiler or an IDE could output a warning such as "hey, there is something with base64 in your code, I hope that is not a cryptographic use case?" or "be aware that md5 and sha1 should be avoided if this use case needs cryptographic security", or at least suggest hmac for sha1. If a known implementation of a cryptographically-secure algorithm such as SHA256 is imported and used without any iteration, it might raise a related warning, too. And so on. This can already facilitate to avoid these issues in some places, and maybe raise some security awareness.
Your tools have to be put in place where such developers look for tools (they look for compilers, interpreters, IDEs, ...), while the reasoning of these developers (or of those who set up environments such as that Solarwinds was using) tends to not end up at dedicated security tools (I was reading the very interesting comment of David about Solarwinds :)
So this is partly less a computer science but a social science problem, including the question why such an "unaware reasoning" has developed and remains competitive in many environments (and how to make security tools comparably competitive within)... Of course these are no dedicated open source problems but more generic ones.

I genuinely value this ask and totally understand where you're coming from, but if the compiler always warns on base64 you regardless of its actual use, then it ends up being false positives, cry wolf, and other cases which makes users end up ignoring it.
Would we want to approach it differently than just compiler/run-time messages?

Generally, it were just examples to illustrate the point. I absolutely understand your argument. A realistic compromise would have to be somewhere in between.
However, to stick for a moment with the base64 example:
On one hand, a developer who uses base64 for crypto use cases does this not by intention but because of a lack of knowledge and awareness. If we can make this developer to read this warning message just once, the job can be already done: deciding to ignore the message in future, or to turn off the message, already implies that the information of the message was processed in the developer's mind. As funny as it sounds, in many cases, this is already a step forward. It is the reasoning that has to be evaluated before solutions can be found: what is the reasoning of someone who sets up build environments that make use of unencrypted TFTP for critical data on the Internet, or uses base64 where crypto is necessary?
On the other hand, further conditions can be added before a warning is provoked. I agree that base64 itself should not be the sole condition before a warning is output. Nevertheless, I am myself not sure if the outcome of this specific approach would justify the efforts. As I said, it is just an example to make a bit aware that just developing good security tools for unaware developers does not automatically end up in these developers deploying them. Having good tools is not sufficient, critical is to bring these tools to those who do not know that they need them.
Alternatives are integration in what such developers look for, or making their tools more security by default. Of course this is not just about development or cryptography. libvirt-based virtual networks are widespread and can be involved directly or indirectly in many use cases, but usually they are by default vulnerable to spoofing because filters have to be put in place manually (which means someone has to be aware of the issue). This can be easily mitigated by enabling existing pre-defined filters by default. Obviously, this is one of many examples of good (and imho even easy-to-deploy) tools that already exist but that remain often unused. So there is also a lot of superficial what can be done, without developing something dedicated, whereas the critical problem is always the same: (how to) bring it to those who need it, maybe without knowing their need themselves. My point in general is not a technical one :)

Would we want to approach it differently than just compiler/run-time messages?

I am open to every incentive. Do you mean anything in particular?

I think this problem is very very hard, but it seems easy.
There are two pieces to this, the technology and the policy.
The technology is the easy part. We need a static analyzer to flag certain algorithms as bad. This is not unlike detecting and preventing strcpy use in modern compilers and static analyzers. It might make more sense to start documenting how various tools can detect the functions/methods/libraries in question to figure out the gaps. Just knowing how to detect unwanted algorithms is extremely helpful even if you have no policy in place, by itself such an effort would have value.
The much harder part is policy. Assuming we can properly detect usage of the cryptographic features, now we have to find a wya to understand what we can or can't use. My policy may differ from your policy in incompatible ways. For example I've seen orgs that outright have banned md5, and some just say "no md5 for security functions". md5 would be easy to blanket ban as an industry because it's so terrible, but there are many algorithms, key sizes, and libraries that aren't necessarily good or bad.
I'm not convinced the OpenSSF should be creating policy suggestions such as this, I could be swayed by a good argument. If we ever did to this, the Best Practices Working Group would be the right home.
And finally, bringing the two together, I think the policy isn't effective without the technology. It's very easy to create policy that's unenforceable. We could create a list of unsafe hashing algorithms (there are several of these already), but if nobody can figure out if they are following a policy, is it really a policy?


Update packages to support User Managed Identities

When trying to use this against an App Service that has a User Managed Identity, you receive the following error:
The identity ids must not be null or empty for 'UserAssigned' identity type.
This is due to the version of Microsoft.Azure.Management.Websites. I updated from 2.1.0 to 2.2.0 which fixes it.
Note: If using User Managed Identities, you additionally need to give "Managed Identity Operator" on the Managed Identity to the App Registration.
I also updated the version of Microsoft.Rest.ClientRuntime.Azure.Authentication  from 2.3.8 to 2.4.0 as the current version is actually unlisted on NuGet.

Thank you, I've updated all NuGet packages in my branch and will publish a new version soon


Add Parameters but not render

Thanks for contributing to Swashbuckle.AspNetCore! As per the contributing guidelines, please adhere to the following rules of thumb before submitting your issue:
Version="5.0.0-rc2"
public class HeaderOperationFilter: IOperationFilter
{
    public void Apply(OpenApiOperation operation, OperationFilterContext context)
    {
        operation.Parameters.Add(new OpenApiParameter()
        {
            Description = "sessionId",
            Name = "sessionId",
            In = ParameterLocation.Header
        });
    }
}

and also
options.OperationFilter();
swagger.json has these Parameters

but

the  OpenApiParameter must has the parameter  Schema
Schema = new OpenApiSchema() { Type = "string"}


wllvm: 1.1.3 -> 1.1.5

Bump :).
Haven't tested extensively,
but looks fine after quick testing.
Behaves differently when reading input
from stdin:
https://github.com/travitch/whole-program-llvm/commit/bb16facc2a23dc433342932981acc6df92520216
Which may or may not be desirable.

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Success on aarch64-linux (full log)
Attempted: wllvm
Partial log (click to expand)
warning: no previously-included files matching '*' found under directory 'test'
warning: no previously-included files found matching 'doc'
writing manifest file 'wllvm.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
/nix/store/hd29mvydx7hjh5p1c2ibd5p2cf8fmrkf-wllvm-1.1.5

Success on x86_64-linux (full log)
Attempted: wllvm
Partial log (click to expand)
warning: no previously-included files matching '*' found under directory 'test'
warning: no previously-included files found matching 'doc'
writing manifest file 'wllvm.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
/nix/store/cqk2y5frm3qcbia079m1xii9b06q4pxa-wllvm-1.1.5

Success on x86_64-darwin (full log)
Attempted: wllvm
Partial log (click to expand)
warning: no previously-included files matching '*' found under directory 'test'
warning: no previously-included files found matching 'doc'
writing manifest file 'wllvm.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
/nix/store/8prxnzwi9vrjay4z1j2ivkg0w5icca8f-wllvm-1.1.5


Combination of PRs #64 and #66

These have a bunch of merge conflicts with each other, and I needed to
merge them anyway to get a version of towncrier I can use to release
my thing, so I figured I'd push the merge as an alternative PR.
If you like both of them, then merging this is a quick way to do that
and skip dealing with the conflicts again. Alternatively, we can
handle them one at a time. Just don't try to merge all three of these
:-)

Codecov Report

Merging #67 into master will increase coverage by 1.95%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #67      +/-   ##
==========================================
+ Coverage   81.81%   83.77%   +1.95%
==========================================
  Files          12       12
  Lines         407      456      +49
  Branches       51       54       +3
==========================================
+ Hits          333      382      +49
  Misses         53       53
  Partials       21       21

Impacted Files
Coverage Δ

src/towncrier/test/test_write.py
100% <ø> (ø)
:arrow_up:

src/towncrier/test/test_settings.py
100% <100%> (ø)
:arrow_up:

src/towncrier/test/test_cli.py
100% <100%> (ø)
:arrow_up:

src/towncrier/_settings.py
77.77% <100%> (+1.91%)
:arrow_up:

src/towncrier/__init__.py
68.33% <100%> (ø)
:arrow_up:

src/towncrier/test/test_format.py
100% <100%> (ø)
:arrow_up:

src/towncrier/_builder.py
97.59% <100%> (+0.48%)
:arrow_up:

Continue to review full report at Codecov.

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


FederatedStore: Change Schema - Remove property

No longer within the realm of FedStore but better suited to individual store implementations.


Make the scoop install command copy+paste without editing

Make the required powershell commands copy and pastable without careful selection or editing
The react-syntax-highlighter for powershell is intended for ps1 scripts, not typing into the shell with an extra ">" character there, which breaks the syntax with the error: "> : The term '>' is not recognized as the name of a cmdlet,"

Thanks for the proposal. It's merged and deployed 🚀


Weird behaviour of SceneViewer launch intent when http is used

Description
For local development, I'm using a simple http server to serve model-viewer.
However, SceneViewer does not launch.
After some testing with the intent URL, the behaviour is indeed weird:
An intent such as
<a href="intent://arvr.google.com/scene-viewer/1.0?file=http://<IP_ADDRESS>/gramophone.glb#Intent;scheme=https;package=com.google.android.googlequicksearchbox;action=android.intent.action.VIEW;S.browser_fallback_url=https://developers.google.com/ar;end;">Avocado

will work (file uses http but schema is https), but the one model-viewer uses would be
<a href="intent://arvr.google.com/scene-viewer/1.0?file=http://<IP_ADDRESS>/gramophone.glb#Intent;scheme=http;package=com.google.android.googlequicksearchbox;action=android.intent.action.VIEW;S.browser_fallback_url=https://developers.google.com/ar;end;">Avocado

which does exactly nothing - also doesnt launch the fallback (this is with the schema automatically extracted from the URL).
I want the first behaviour to have it work :)
I guess there are three questions here; "what does that schema thing even do", "why do the two need to be different for this to work", "would it be possible to work around this"?
Live Demo
You'll need to use the above code locally (with any simple local http-server) and serve a glb file.
Browser Affected

[X] Chrome
[ ] Edge
[ ] Firefox
[ ] Helios
[ ] IE
[ ] Safari

OS

[X] Android
[ ] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

Thank you, this looks like a bug to me. @tpsiaki, can you comment on the http vs https thing here? I'm a little surprised changing the intent in this way makes it work.

SceneViewer officially only supports the HTTPS intent;
@tpsiaki please don't take this workaround away from me for local testing 🙏

Thanks for finding this workaround for local testing of SceneViewer. I decided to hard-code https into the intent to make this easier in #1475.

Oooh, this is great, thanks - I didn't dare make a PR with such a hack 🧷 (changed it locally in our fork).