jrruethe

#!/usr/bin/env ruby

# https://asmirnov.xyz/vram
# https://vram.asmirnov.xyz

require "fileutils"
require "json"
require "open-uri"

# https://huggingface.co/spaces/NyxKrage/LLM-Model-VRAM-Calculator/blob/main/index.html

michaelsbradleyjr

Next-gen Joose

My goal is to outline some of my thoughts on how a next-gen Joose (e.g. Joose4) might be structured around AMD style modules and avoid use of global namespaces, for Joose itself and Classes, Roles, etc. that are defined with Joose.Class(), Joose.Role(), etc.

This is an outline only, and not an attempt to rigorously solve all of the technical problems faced in such a big shift in the design of the Joose object system.

AMD require, define are assumed to be implemented

As hinted at above, this outline will assume that runtime environment fully supports the AMD spec. For browsers, that means using an implementation like RequireJS. For node.js, that means creating some sort of "shim" so that modules defined with asynchronous loading in mind will work without modification and alongside synchronously loaded modules. RequireJS, for example, provides an r.js adapter for use with node.js, but at pres