Skip to content

Instantly share code, notes, and snippets.

View index.html
<!DOCTYPE html>
<html>
<head>
<title>Ingekleed vraagstuk: dakdekkerslift huren en plaatsen</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="bootstrap4/css/bootstrap.css">
@GerHobbelt
GerHobbelt / making-javascript-faster.md
Last active Mar 8, 2022
Making Javascript faster
View making-javascript-faster.md

Making Javascript faster

This is a list of guidelines to make your Javascript faster, often associated with jsPerf benchmarks.

Profile before optimizing

If you have an existing codebase, don't get carried away with premature optimizations. Profile to find the slow bits and pick the low hanging fruit.

@GerHobbelt
GerHobbelt / README.md
Last active Aug 29, 2015
Response to PEGjs question in the mailing list -- big for a response; blog entry size but still lacking context to be able to stand on its own
View README.md

Note: I'm not native English speaking and don't have the natural language processing jargon down pat, so the 'preceeding' vs. 'proceeding' I assume the PREceeding text before 'x' in 'zzxz' is the leading 'zz' ('history') and the PROceeding text for the same is the trailing 'z', hence 'proceeding text' would be similar to 'look ahead' as it is called in computer language parsing (unambiguous language parsing).

Anyway... I'm sure I don't get everything you say but there's at least one subject which is certainly relevant here:

handling/coping with history (preceeding input) vs. look-ahead (future, incoming, proceeding input)

In your sample grammar and sample 'zzxz' I assume each character is a single token. (Yes, PEG always processes characters as it blends lexer and parser into a single specification language; I'm just sufficiently dinosaur to appreciate the difference between 'character stream' and 'token stream': the token stream is where such nice horrors as left recursion are to be ex

@GerHobbelt
GerHobbelt / README.md
Created Aug 25, 2014
collapsible D3.js force layout + dat.gui for fiddling
@GerHobbelt
GerHobbelt / README.md
Last active Jul 6, 2016
JISON sample wrapper showcasing custom error handlers (stripped JavaScript, ... where more must be done)
View README.md

This code is a stripped version of actual production code which employs this JISON clone:

(https://github.com/GerHobbelt/jison)

hence make sure to diff that one against vanilla to see differences/features.


code shows .yy.parseError, lexer.post_lex, parser.post_parser, how to get the token identifier strings from the JISON-generated parser class, etc.

@GerHobbelt
GerHobbelt / 0_reuse_code.js
Created Jan 7, 2014
Here are some things you can do with Gists in GistBox.
View 0_reuse_code.js
// Use Gists to store code you would like to remember later on
console.log(window); // log the "window" object to the console
@GerHobbelt
GerHobbelt / grammar-extract.jison
Last active Nov 17, 2019
snip&snap extracts from our major JISON grammar file, showcasing 'code sections' a la BISON plus a few other bits & tricks. Note the %{ ... %} sections which are JISON's 'code sections'. Also note the code following that last '%%' marker: that is another 'code section' - and the most important one.
View grammar-extract.jison
%options ranges
%options backtrack_lexer
/*
* lexical grammar
* ===============
*
* This section defines the lexer rules for our formula parser. The rules are checked from top to bottom, so order is import
* here!
*
@GerHobbelt
GerHobbelt / README.md
Last active Dec 15, 2015
reference scans for the new D3.js scales+axis work-in-progress
View README.md

Intent

Collection of references ('from a time when graphic skills did not mean hitting the Print button on an Excel Chart')

Origins

Scans originate from some classic books, owned by yours truly:

@GerHobbelt
GerHobbelt / .gitattributes
Last active Dec 10, 2015
Staafjespuzzel code from Henk, tweaked. (36cube puzzle)
View .gitattributes
*.sh text eol=lf
*.php text eol=lf
*.inc text eol=lf
*.html text eol=lf
*.js text eol=lf
*.css text eol=lf
*.ini text eol=lf
*.txt text eol=lf
*.xml text eol=lf
*.md text eol=lf
@GerHobbelt
GerHobbelt / README.md
Created Sep 23, 2012
JavaScript: a state-machine-based lexer + recursive descent (LL(k)) grammar parser + abstract syntax tree (AST) + generator
View README.md

Basic Compiler Technology

Lexers, Parsers, Code Generators are of all ages (old skool: lex/flex, yacc/bison (modern-ish: PCCTS/ANTLR), burg/lburg/...)

Here's an example of a JavaScript based domain-specific language being parsed and converted into HTML. It is very similar to wiki and MarkDown formats; the only purpose of this code is to showcase the parsing technology, so a minimum number of 'shortcuts' and other production code 'smartness' is applied.

The recursive descent parser works by evaluating the grammar rules in order of precedence, where each function call is a grammar rule match attempt and the first one returning success is a 'grammar rule match' which will allow the parser to continue parsing the input.

Also, the input is assumed to be size limited, i.e. a infinite lookahead grammar is fine with us. (This doesn't work in situations where you need to parse a stream, but that is a problem area that few of us have to deal with in actual reality. Mostly we like limited lookahead grammars becaus