Ruby Parser開発日誌 (1) - かねこにっき
Error Tolerant parserに関するアイデア 9月半ばに行われたRubyKaigi 2022以来、3ヶ月くらいError Tolerant parserについて調べたり考えたり実装をしたりしています。 途中でもいいからなにかにアウトプットしておくとよいというアドバイスをもらったので、今現在の状況や考えていることを書いておこうと思います。 Error Tolerant parserとは? どうしてそれが欲しいの? 通常parserはユーザーの入力を受け取り その入力がそのプログラミング言語にとって、validなものか否かをチェック validな場合、その後の工程にとって都合のいいデータ構造(例えばAST)に変換し、後工程に渡す invalidな場合、Syntax Errorをレポートする といった処理を行います。 しかしIDEやLSP(Language Server Proto
Content EditableでWYSIWYGエディタ作るの楽しい！ - maru source
こんにちは丸山@h13i32maruです。 僕は今、Ubie Discoveryで医療従事者向けのカルテエディタを作っています。人生で初めてContent Editableを使ってエディタを作ってるんですが、それがすごく楽しいです！というのも、エディタを作るには色々技術的な課題があります。例えば、テキストをパースするには？ASTからHTMLをビルドするには？パフォーマンスのよい更新方法は？などなど。それらの技術的な課題を解決していくのが単純に楽しいという感じです。また、車輪の再発明は極力抑えつつ、自分たちのプロダクトでやりたいことを実現できるような工夫もしています。 というわけで、今回はそんなエディタ作りで取り組んだ課題と解決策を紹介していきたいと思います。 （訳: 楽しかったので、誰かに聞いてもらいたい！） エディタの概要 メンテしやすいテキストパーサ - PEG.js メンテしやすいH
Next.js で Node.js の API がいつ入ったのかわかる表を作る
Node.js の API がいつ入ったのかを調べる必要が出てきた。 もちろんリリースノートを見たり、ドキュメントの History を見れば調べられることが多いが、普通に面倒くさいので、いい感じの表とかを自動で生成できたら嬉しい。 どうやら公式ドキュメントは Markdown で管理されており、Added の情報はその Markdown の中のコメントに YAML として書かれているらしい。 なので、Markdown の内容を fetch して Markdown としてパースし、その中の特定のコメントをさらに YAML としてパースすることでデータがとれそうだった。 そして、そのデータをビルド時にひっぱってくる静的サイトがあればいつでも見れて便利だし、ビルド時にしか fetch しないので比較的行儀も良い。 ということで作ったみた。 実際のサイトはこちら https://nodejs-a
TypeScript 4.1による型レベルパーサコンビネーター
はじめに これはTypeScript Advent Calendarの11日目の記事です。 TS 4.1で導入されたTemplate literal typesが世間で話題ですね。 TypeScriptのTemplate string typesで湧き上がる界隈の様子 - Togetter Template String Types でパス文字列を解析してクエリする - Object.create(null) (ネタ) TypeScript 型パズルで作るmini interpreter by Yosuke Kurami TypeScriptにヤバい機能が入りそうなのでひとしきり遊んでみる - TechRacho Template titeral types で型上の簡易 Lisp パーサー - La Verda Luno Template Literal Types の基礎と .join
Rustでインタプリタ
Lexerを作る Lexerとは Lexerとは、入力されたソースコードから構文を読み取り、意味のある形式に変換するための機能。 例えば、
Building a high performance JSON parser
JSON is important, damn near everything that we do as programmers or operators involves JSON at some point. JSON decoding is expensive, if your product talks JSON then performance of marshalling data in and out of JSON is important. This is a talk about designing an efficient replacement for encoding/json.Decoder.
新しいマークダウンパーサーが必要な理由 | NHN Cloud Meetup
最近の開発者が最も好むドキュメント形式を挙げるとしたら断然マークダウンになるでしょう。マークダウンは、GitHub、GitLab、Bitbucketなど、タスクやイシュー管理に対応するほとんどのサービスにおいて、基本のドキュメント形式として使用されています。また、IntelliJ、VSCode、Vim、Emacsなど、ほぼすべてのテキスト編集ツールでも、プラグインを通じてマークダウン文書の強調構文やプレビュー機能を使用することができます。 TOAST UI Editorはここからさらに一歩進んで、マークダウンエディターとウィジウィグエディターを統合した形式のインターフェースを提供しています。ウィジウィグエディターを使用すると、テーブルなどの複雑な文法をより直感的に簡単に編集することができ、マークダウンに慣れていないユーザーでもマークダウン基盤の文書を簡単に編集できます。特に、開発者と非開発
Remark で広げる Markdown の世界
はじめましてこんにちは、はるさめです。本誌は名目上 Vivliostyle について紹介する同人誌なのですが、またしても空気を読まず Vivliostyle ではない OSS プロジェクト「Remark」について紹介したいと思います。 Remark Remark とは「Markdown processor」という紹介文の通り、Remark で書かれたテキストを読み込み様々な変換を施すことができる JavaScript 製のライブラリです。Remark は様々なライブラリと組み合わせて目的の形式のテキストに変換でき、Rehype と一緒に使うことで Markdown を HTML に変換できます。同様の処理をしてくれるライブラリとしては Marked.js が有名ですが、Remark の強力な機能は、Markdown を 抽象構文木（AST）に変換することで、より柔軟に構文を改造できる点です
ノータブルコード2 - 斬新なコメントでコードの可読性を高める - 2020-01-15 - ククログ
この新しいコーナー「ノータブルコード」では、私たちが開発の折々に目にした興味深いコードをご紹介しています。世の中の実際のプロジェクトから、興味深い素材を肩の凝らない形でご紹介していきたいと思いますので、楽しみにしていてください。 Brubeck - 創造的なコメントで見通しを良くする 第2回目に紹介するのは、GitHubが開発したStatsD互換サーバー Brubeck からの一コマです。 int brubeck_statsd_msg_parse(struct brubeck_statsd_msg *msg, char *buffer, char *end) { *end = '\0'; /** * Message key: all the string until the first ':' * * gaugor:333|g * ^^^^^^ */ { msg->key = buffer
JSON Parser with JavaScript | Tan Li Hau
Series: AST JavaScriptAST Understand the grammar Implementing the parser Handling the unexpected input Unexpected token Unexpected end of string Going the extra mile Error code and standard error message A better view of what went wrong Suggestions for error recovery Summary The interview question of the week for this week on Cassidoo's weekly newsletter is, Write a function that takes in a string
JavaScriptの「カバー文法」とは何か - Qiita
この表を上から読みつつ多少言葉で説明すると以下のようになります。 const foo = bar + 3;はStatementListItemである。なぜなら、DeclarationはStatementListItemの一種であると定義されているから。 const foo = bar + 3;はDeclarationである。なぜなら、LexicalDeclarationはDeclarationの一種であると定義されているから。 const foo = bar + 3;はLexicalDeclarationである。なぜなら、LetOrConst, BindingList, ;が並んだものはLexicalDeclarationであると定義されているから。 constはLetOrConstであると定義されている。 foo = bar + 3 はBindingListである。LexicalBind
GitHub - csstree/csstree: A tool set for CSS including fast detailed parser, walker, generator and lexer based on W3C specs and browser implementations
Detailed parsing with an adjustable level of detail By default CSSTree parses CSS as detailed as possible, i.e. each single logical part is representing with its own AST node (see AST format for all possible node types). The parsing detail level can be changed through parser options, for example, you can disable parsing of selectors or declaration values for component parts. Tolerant to errors by
TypeScript の Async/Await と非同期入力
2016-01-15 (鈴) 1. はじめに 2. TypeScript の Async/Await 3. 端末対話入力プロトタイプ 4. Lisp Reader 5. おわりに lisp_reader.ts : Lisp Reader 2016-01-15.tar.bz2 : 上記を含む本稿のプログラム例の詰め合わせ (2898 バイト) 1. はじめに TypeScript (および JavaScript) は従来，コールバックを使って非同期処理を実現してきた。 しかし，この方法には「 Dart のイテレータと非同期処理 」で指摘した欠点がある: コールバック関数が終わるとき関数の呼び出し階層が無に帰するため， 再帰下降法のようなアルゴリズムをそのまま素直には実現できなかった。 従来どおりのアルゴリズムを使えず，処理が細切れのコールバックに寸断されることがプログラミングに困難をもたらし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lark-parser/lark: Lark is a parsing toolkit for Python, built with a focus on ergonomics, performance and modularity.
GitHub - g-plane/typed-query-selector: Better typed `querySelector` and `querySelectorAll`.
GitHub - fb55/htmlparser2: The fast & forgiving HTML and XML parser
Node.jsでウェブスクレイピングする色々な方法 - Qiita
GitHub - thysultan/stylis: light – weight css preprocessor
GitHub - susisu/loquat: Monadic parser combinators for JavaScript / TypeScript
GitHub - DmitrySoshnikov/syntax: Syntactic analysis toolkit, language-agnostic parser generator.
