yawaramin

"""
Bindings for OpenAPI 3.0.0 - https://swagger.io/specification/#schema-object

ℹ️  JSON Schema validation for OpenAPI 3.0.0 must conform to this version:
https://datatracker.ietf.org/doc/html/draft-wright-json-schema-validation-00
"""

schema Ref:
  $ref: str

yawaramin

(* Re: https://twitter.com/llaisdy/status/1558536851560054786?s=20&t=us8J3LvoJTlwVwod5bOqeQ *)

(* Use this if using the REPL, otherwise use dune to build with the library dependency *)
#require "uutf";;

(* Converts an array of ints (Unicode graphemes) into a UTF-8 encoded string. *)
let utf8_to_string uchars =
  let buf = Buffer.create (2 * Array.length uchars) in
  Array.iter (fun uchar -> Uutf.Buffer.add_utf_8 buf (Uchar.of_int uchar)) uchars;
  Buffer.contents buf

yawaramin

-- Run with:
-- $ sqlite3 ecb_rates.db
-- sqlite> .read ecb_rates.sql

drop table if exists eurofxref_hist;
drop table if exists ecb_rates;

create table ecb_rates (
  date text not null,
  curr text not null,

yawaramin

#!/usr/bin/env sh

usage() {
  cat <<EOF
USAGE
  $(basename $0) FILENAME [COMMENT]

  Get or set file comment.

ARGUMENTS

yawaramin

(* Good morning everyone, I'm currently learning ocaml for one of my CS class and needed to implement
   an avl tree using ocaml. I thought that it would be interesting to go a step further and try
   to verify the balance property of the avl tree using the type system. Here's the resulting code
   annotated for people new to the ideas of type level programming :)
*)

(* the property we are going to try to verify is that at each node of our tree, the height difference between
   the left and the right sub-trees is at most of 1. *)

yawaramin

[@bs.module "formik"]
[@react.component]
external make: (
  ~initialValues: Js.t('a),
  ~validate: (. Js.t('a)) => Js.Dict.t(string),
  ~onSubmit: (. Js.t('a), {. "setSubmitting": [@bs.meth] bool => unit }) => unit,
  ~children: (. {. "isSubmitting": bool }) => React.element,
) => React.element = "Formik";

module Form = {

yawaramin

// @flow

import type { $Request, $Response, Middleware, NextFunction, Router } from 'express'

type Path = express$Path | express$Path[]

export type TypedMiddleware<A> =
  | ((req: $Request & A, res: $Response, next: NextFunction) => mixed)
  | ((error: Error, req: Request & A, res: $Response, next: NextFunction) => mixed)

yawaramin

/* @flow */

type NonNegativeInt = number
type PositiveNumber = number
type Regex = string

type SchemaType = {
  description?: string,
}

yawaramin

Local imports in Scala

https://github.com/ghik/opinionated-scala/wiki/Packages-and-imports#local-imports

Local imports are very nice tool to minimize the impact of your imports and protect yourself from accidentally polluting too wide namespaces with imports that you need only in small, local context. That's especially important when using wildcard imports (see later).

Cay Horstmann, Scala for the Impatient, §7.8 (Imports can be anywhere)

In Scala, an import statement can be anywhere, not just at the top of a file.

yawaramin

I propose here a new convention and design for a tool to auto-generate API documentation for source code in any language, with no dependencies or intricate build commands. Here are my assumptions:

• Source code in plain text format
• Language supports comments, either single- or multi-line (multi-line would be easier to use for documentation)
• A convention to interpret comments starting with a certain character as documentation comments, e.g. for OCaml we would use (** to mark the start of documentation comments.

Given the above, we can create a tool that has the following UI:

doctool [--output-dir DIR] --start STARTSTR --end ENDSTR --lang LANGUAGE FILE...