| module.exports = function compile(str) { | |
| var code = "var p=[],print=function(){p.push.apply(p,arguments);};" | |
| + "with(obj){p.push('" + str.replace(/[\r\t\n]/g, " ") | |
| .split("<@").join("\t") | |
| .replace(/((^|@>)[^\t]*)'/g, "$1\r") | |
| .replace(/\t=(.*?)@>/g, "',$1,'") | |
| .split("\t").join("');") | |
| .split("@>").join("\np.push('") | |
| .split("\r").join("\\'") + "');}return p.join('');"; | |
| return new Function("obj", code); |
This benchmark has been misleading for a while. It was originally made to demonstrate how JIT compilers can do all sorts of crazy stuff to your code - especially LuaJIT - and was meant to be a starting point of discussion about what exactly LuaJIT does and how.
As a result, its not indicative of what its performance may be on more realistic data. Differences can be expected because
| function translateError(msg) { | |
| var newErr = new Error(msg); // placed here to get correct stack | |
| return e => { | |
| newErr.originalError = e; | |
| throw newErr; | |
| } | |
| } | |
| async function asyncTask() { | |
| const user = await UserModel.findById(1).catch(translateError('No user found')) |
| // ==UserScript== | |
| // @name ChatGPT save to Markdown button | |
| // @author spion, avosirenfal | |
| // @description Adds an export button for exporting the doc to markdown | |
| // @namespace chatgpt | |
| // @version 1.0.0 | |
| // @match https://chat.openai.com/* | |
| // @grant none | |
| // @run-at document-start | |
| // ==/UserScript== |
| version: '3.6' | |
| services: | |
| keycloak_one: | |
| image: quay.io/keycloak/keycloak:16.1 | |
| volumes: | |
| - keycloak_one_data:/opt/keycloak/data | |
| command: start-dev | |
| ports: | |
| - 8081:8080 | |
| environment: |
This guide describes what steps usually work best when adding new features to a product. The guidelines are not mandatory; simpler features may not need any of these steps. They exist to help battle the hardest new features to add :)
The steps are not necessarily in the correct order - this is the usual order. Going back to an older step to add/change things is okay.
Goal: collect all that we can come up with for the new feature or change. Everything goes into an unorganized document (wiki page). Possible ways to organize this document is into proposal items (and proposal detail item for each proposal item).
| import { ApiObject, GroupVersionKind, Include } from "cdk8s"; | |
| import { Construct } from "constructs"; | |
| import * as immer from "immer"; | |
| import * as fs from "fs"; | |
| type UnReadonly<T> = T extends string | number | boolean | null | |
| ? T | |
| : T extends ReadonlyArray<infer U> | |
| ? Array<UnReadonly<U>> | |
| : { -readonly [K in keyof T]: UnReadonly<T[K]> }; |
| // Usage: phantomjs screenshot.js 1920x1080 site.domain.com | |
| // outputs to site.domain.com-1920x1080.png | |
| // dont add http to the URL | |
| // If the page didnt render in time add a delay argument | |
| // e.g. 3000 for 3 seconds | |
| var page = require('webpage').create(); | |
| var args = require('system').args; | |
| var wh = args[1].split('x'); |
It's easy to trip up on the meaning of this in JavaScript. The behavior is very different from other languages, which means we have to throw most preconceptions and intuition out the window.
The best way to think of this in JS is as a hidden function argument which is passed in a slightly awkward way. Instead of the normal passing of arguments:
fn(arg1, arg2, arg3)