JSDoc in question:

/**
 * [BLAKE2b] hash algorithm implemented in WebAssembly.
 *
 * ```js
 * const message = new TextEncoder().encode("hello")
 * new Blake2b(32)
 *   .update(message)
 *   .digest();
 * // Uint8Array(32) [ 50, 77, 207, ... ]
 * ```
 *
 * [BLAKE2b]: https://www.blake2.net/blake2.pdf
 */

Renders in doc.deno.land without the text-blue-500 class:

Rendered HTML:

<p><a href="https://www.blake2.net/blake2.pdf">BLAKE2b</a> hash algorithm implemented in WebAssembly.</p>

Should I issue separate PRs for each rule I've refactored or just single PR?

I think either way is fine!

Ooops I forgot to remove this test which was just for debugging. Thanks :D

        col: 13,

Very small nit: extra whitespace here (same for the other test cases)

Deleting double use of string.replace speeding up the parsing.

Tried the benchmark like the below, parsing of a toml which contains 1000-line multiline string literal.

import { parse } from "./encoding/toml.ts";

const toml = "data = '''" + [...Array(1000)].map(() => 'foo').join('\n') + "'''"

const timeStarted = Date.now();
for (const _ of Array(1000)) {
  parse(toml);
}
const timeEnded = Date.now();

console.log(`elapsed time: ${timeEnded - timeStarted}ms`);

520~530ms in main branch, 470~480ms in this branch consistently. I confirmed this is actually an improvement of parsing of large string literals.

Sorry for the slow response. Magic already has code that builds it as an extension of Tcl and another code set that embeds a scheme interpreter (and presumably for Rust you would want do disable both of those). Both of those change the entire command binding from magic's control to an interpreter's control, and then all of magic's commands get reimplemented in the interpreter. Check the difference between TxDispatch and _tcl_dispatch. TxDispatch is definitely a good target for that. For Tcl/Tk, I have a simple routine that registers every command in magic to a single Tcl routine that calls _tcl_dispatch (see tcltk/tclmagic.c), which in turn calls TxTclDispatch() which is a replacement for the original TxDispatch(). by replacing TxDispatch() with TxTclDispatch(), I'm cutting txGetInteractiveCommand() out of that loop.

I did all this a very long time ago, so the details are definitely a bit fuzzy.

Hi! Website https://deno.land loads very slowly, and then gives the error 525.

but if I use a VPN and go to the site from Hong Kong - everything works well!

is there deadline for stable realase std library for deno ? I think the most missing thing in deno ecosys at this moment

Yes, I know. . . it's just rather low on my priority list. I guess when somebody bugs me about it, it gets bumped up on the list, so now that you've pointed it out I'm going to have to go do something about it. . .

@wperron @kt3k Thanks for the review!

If I run this in the browser, it seems like the handler runs before the error. Don't know if it's just a quirk in the console output of Dev Tools.

Promise.resolve().then(() => {
  console.log(3);
});
console.log(1);
throw new Error('abc');
console.log(2);

// 1
// 3
// Uncaught Error: abc

In Node, require("stream") returns Stream itself with all the other kinds of streams as properties. This maps to the default export for ESM, so I've changed the default export of stream.ts to be Stream and added all the other streams as properties.

👍

Closes #872.

Changes

• Added assert.rejects and assert.doesNotReject
• Fixed util.inspect to enclose strings in single quotes instead of double quotes
• Introduced validateThrownError internal function to remove duplication between assert.throws and assert.rejects
• Introduced gotUnwantedException internal function to remove duplication between assert.doesNotThrow and assert.doesNotReject
• Enabled test-assert-async.js
• Fixed ERR_INVALID_ARG_TYPE to properly construct error messages

assert.rejects is used in some native node tests.

This fix is helpful for other node compat implementations! Thanks!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

👀 👍

Deno.core.opSync and Deno.core.opAsync should probably be moved out of core to the normal Deno namespace

http://opencircuitdesign.com/magic/

Refactored rules (#431)

• extracted rule name into CODE constant
• introduced enum value that displays proper message/hint
• used assert_lint_err! macro in one-line tests

Thanks for the example. Should I issue separate PRs for each rule I've refactored or just single PR?

@kamchy thanks! There's not much difference between the rules left - this task is mostly about switching rules from using assert_lint_err::<> and assert_lint_err_n::<> to using assert_lint_err! macro. I think starting with eqeqeq might be good first try. As an example here's how to use assert_lint_err! macro in for_direction rule

There are not many rules to refactor left, perhaps I could help here?