anil.recoil.org / thicket-eeg
Thicket data repository for the EEG
fork atom
thicket-eeg / ryan / 2025-05-19.html.json
at main 14 kB view raw
1{ 2 "id": "https://ryan.freumh.org/2025-05-19.html", 3 "title": "19 May 2025", 4 "link": "https://ryan.freumh.org/2025-05-19.html", 5 "updated": "2025-05-19T00:00:00", 6 "published": "2025-05-19T00:00:00", 7 "summary": "<div>\n <span> Previous: <a href=\"2025-05-12.html\">12 May 2025</a> </span>\n <span> </span>\n </div>\n \n \n\n <h2>The Package Calculus</h2>\n<p><span>I’ve been updating the package\nmanagement paper, which I include a snippet of below. I’m extending this\ncore Package Calculus to support modelling real-world package managers,\nand showing a reduction to the core. I’m going to use this as the basis\nfor bi-directional translations between package management\necosystems.</span></p>\n<h3>Formalising Dependency Resolution</h3>\n<p><span>We present the Package Calculus, a\nformal system for analysing dependency resolution in package management\nsystems. Based on the Package Calculus, we define a language\n<em>Pac</em> for expressing dependencies to be resolved. This calculus\ncaptures the essential complexity of version selection while remaining\nexpressive enough to model real-world package managers.</span></p>\n<ol>\n<li><p><span>The Package Calculus</span></p>\n<ol>\n<li><p><span>Package</span></p>\n<p><span>We define:</span></p>\n<ul>\n<li><span><em>N</em></span> is a set of possible\npackage names,</li>\n<li><span><em>V</em></span> is the set of possible\npackage versions,</li>\n<li><span><em>P</em> = <em>N</em> × <em>V</em></span> is the\nset of possible packages,</li>\n<li><span><em>R</em> ⊆ <em>P</em></span> is the set\nof packages which exist.</li>\n</ul></li>\n<li><p><span>Dependency</span></p>\n<p><span>Dependencies <span><em>D</em> ⊆ <em>P</em> × (<em>N</em> × 2<em>V</em>)</span>\nare a relation from packages to a name and set of versions. We denote an\nelement of <span><em>D</em> ∋ ((<em>n</em>, <em>v</em>), (<em>m</em>, <em>v</em><em>s</em>))</span>\nwith <span>(<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>)</span>\nwhere a package <span>(<em>n</em>, <em>v</em>)</span> expresses a\ndependency on a package name <span><em>m</em> ∈ <em>N</em></span> and set of compatible\nversions <span><em>v</em><em>s</em> ⊆ <em>V</em></span> which can\nsatisfy the dependency. The set of versions <span><em>v</em><em>s</em></span> is often expressed with\n/dependency formula/ which we abstract to a set. Every package\nreferenced by <span><em>D</em></span> must be in\n<span><em>R</em></span>, <span>(<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>) ⟹ (<em>n</em>, <em>v</em>) ∈ <em>R</em> ∧ {(<em>m</em>, <em>u</em>) ∣ <em>u</em> ∈ <em>v</em><em>s</em>} ⊆ <em>R</em></span>.</span></p></li>\n<li><p><span>Resolution</span></p>\n<p><span>Given a set of dependencies <span><em>D</em></span> and a query set <span><em>Q</em> ⊆ <em>P</em></span> a resolution <span><em>S</em> ⊆ <em>P</em></span> is valid if the\nfollowing conditions hold:</span></p>\n<ol>\n<li><p><span><strong>Query Inclusion</strong>:\n<span><em>Q</em> ⊆ <em>S</em></span></span></p></li>\n<li><p><span><strong>Dependency\nClosure</strong>: <span>∀<em>p</em> ∈ <em>S</em>, <em>p</em> → (<em>n</em>, <em>v</em><em>s</em>) ⟹ ∃(<em>n</em>, <em>v</em>) ∈ <em>S</em> : <em>v</em> ∈ <em>v</em><em>s</em></span></span></p>\n<p><span>If <span><em>p</em></span> is in <span><em>S</em></span> and <span><em>p</em></span> depends on <span>(<em>n</em>, <em>v</em><em>s</em>)</span> then there\nexists a <span>(<em>n</em>, <em>v</em>)</span> in\n<span><em>S</em></span> where <span><em>v</em></span> is in the set <span><em>v</em><em>s</em></span>.</span></p></li>\n<li><p><span><strong>Version\nUniqueness</strong>: <span>∀(<em>n</em>, <em>v</em>), (<em>n</em>, <em>v</em>′) ∈ <em>S</em>, <em>v</em> = <em>v</em>′</span></span></p>\n<p><span>Packages of the same name in <span><em>S</em></span> must have the same\nversion,</span></p></li>\n</ol>\n<p><span>We write <span>𝒮(<em>D</em>, <em>Q</em>)</span> for the set of all\nresolutions of <span><em>Q</em></span> in <span><em>D</em></span>.</span></p></li>\n</ol></li>\n<li><p><span>The Language\n<em>Pac</em></span></p>\n<p><span>Let <span><em>n</em> ∈ <em>N</em></span> and <span><em>v</em> ∈ <em>V</em></span>, then we define the\nexpression language <em>Pac</em> by the following grammar:</span></p>\n<pre><code>p ::= n v vs :== v+ t ::= n ( v+ ) d ::= p ( t^* ) e ::= d^*\n</code></pre>\n<p><span>We extract <span><em>D</em></span> and <span><em>R</em></span> from an expression <span><em>e</em></span> with</span></p>\n<pre><code>d = p ( t^* ) e,m vs t^*, p (m, vs) p R\n</code></pre>\n<ol>\n<li><p><span>Example Mapping from a\n<em>Pak</em> expression to dependencies:</span></p>\n\n\n \n \n <pre>A 1 ( B (1) C (1) )\nB 1 ( D (1 2) )\nC 1 ( D (2 3) )\nD 1 () D 2 () D 3 ()\n </pre>\n \n ⟹\n \n <pre>(A,1) → (B,{1})\n(A,1) → (C,{1})\n(B,1) → (D,{1,2})\n(C,1) → (D,{2,3})\n </pre>\n \n \n \n <em>Grammar expression e</em>\n \n <em>Dependencies relation D</em>\n \n\n\n<p><span>We illustrate this example in figure\n<a href=\"#fig:hypergraph\">1</a> as a directed hypergraph, a graph where\nedges are hyperedges from a package (the domain) to a set of packages\n(the codomain). The hypergraph has vertices <span><em>R</em></span> and hyperedges <span><em>E</em> = {({(<em>n</em>, <em>v</em>)}, {(<em>m</em>, <em>u</em>) ∣ <em>u</em> ∈ <em>v</em><em>s</em>}) ∣ (<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>)}</span>.\nNote that we restrict the domain to a size of one – we can only express\na dependency <em>from</em> one package. The only resolution for the\nquery <span><em>Q</em> = {(<em>A</em>, 1)}</span> is\n<span><em>S</em> = {(<em>A</em>, 1), (<em>B</em>, 1), (<em>C</em>, 1), (<em>D</em>, 2)}</span>.</span></p>\n\n\n\n\n<img src=\"./images/2025-05-19-hypergraph.svg\">\n\nFigure 1: A Resolution Hypergraph\n</li>\n</ol></li>\n</ol>\n<h2>Matrix VoIP</h2>\n<p><span>I’ve <a href=\"https://github.com/RyanGibb/eilean-nix/commit/a4eca30597164f4a9b76dd4b35fc4cd0b808c744\">tried</a>\nand failed to add the new Matrix <a href=\"https://github.com/element-hq/element-call/blob/livekit/docs/self-hosting.md\">Element\nCall stack</a> to <a href=\"eilean.html\">Eilean</a>. I think it’s probably\na misconfigured <a href=\"https://github.com/livekit/livekit\">LiveKit</a>\nturn server.</span></p>\n<h2><a href=\"bigraphs-real-world.html\">Bigraphs of the Real World</a></h2>\n<p><span>I was proof reading the\nlast versions of <a href=\"https://github.com/royangkr/\">Roy</a>’s\nthesis, which was just submitted! I’ve excited to try incorporating some\nof <a href=\"https://github.com/royangkr/bigraph-of-the-world\">his\nwork</a> into <a href=\"eon.html\">Eon</a> as a step towards the <a href=\"spatial-computing.html\">Spatial Name System</a>.</span></p>", 8 "content": "<div>\n <span> Previous: <a href=\"2025-05-12.html\">12 May 2025</a> </span>\n <span> </span>\n </div>\n \n \n\n <h2>The Package Calculus</h2>\n<p><span>I’ve been updating the package\nmanagement paper, which I include a snippet of below. I’m extending this\ncore Package Calculus to support modelling real-world package managers,\nand showing a reduction to the core. I’m going to use this as the basis\nfor bi-directional translations between package management\necosystems.</span></p>\n<h3>Formalising Dependency Resolution</h3>\n<p><span>We present the Package Calculus, a\nformal system for analysing dependency resolution in package management\nsystems. Based on the Package Calculus, we define a language\n<em>Pac</em> for expressing dependencies to be resolved. This calculus\ncaptures the essential complexity of version selection while remaining\nexpressive enough to model real-world package managers.</span></p>\n<ol>\n<li><p><span>The Package Calculus</span></p>\n<ol>\n<li><p><span>Package</span></p>\n<p><span>We define:</span></p>\n<ul>\n<li><span><em>N</em></span> is a set of possible\npackage names,</li>\n<li><span><em>V</em></span> is the set of possible\npackage versions,</li>\n<li><span><em>P</em> = <em>N</em> × <em>V</em></span> is the\nset of possible packages,</li>\n<li><span><em>R</em> ⊆ <em>P</em></span> is the set\nof packages which exist.</li>\n</ul></li>\n<li><p><span>Dependency</span></p>\n<p><span>Dependencies <span><em>D</em> ⊆ <em>P</em> × (<em>N</em> × 2<em>V</em>)</span>\nare a relation from packages to a name and set of versions. We denote an\nelement of <span><em>D</em> ∋ ((<em>n</em>, <em>v</em>), (<em>m</em>, <em>v</em><em>s</em>))</span>\nwith <span>(<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>)</span>\nwhere a package <span>(<em>n</em>, <em>v</em>)</span> expresses a\ndependency on a package name <span><em>m</em> ∈ <em>N</em></span> and set of compatible\nversions <span><em>v</em><em>s</em> ⊆ <em>V</em></span> which can\nsatisfy the dependency. The set of versions <span><em>v</em><em>s</em></span> is often expressed with\n/dependency formula/ which we abstract to a set. Every package\nreferenced by <span><em>D</em></span> must be in\n<span><em>R</em></span>, <span>(<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>) ⟹ (<em>n</em>, <em>v</em>) ∈ <em>R</em> ∧ {(<em>m</em>, <em>u</em>) ∣ <em>u</em> ∈ <em>v</em><em>s</em>} ⊆ <em>R</em></span>.</span></p></li>\n<li><p><span>Resolution</span></p>\n<p><span>Given a set of dependencies <span><em>D</em></span> and a query set <span><em>Q</em> ⊆ <em>P</em></span> a resolution <span><em>S</em> ⊆ <em>P</em></span> is valid if the\nfollowing conditions hold:</span></p>\n<ol>\n<li><p><span><strong>Query Inclusion</strong>:\n<span><em>Q</em> ⊆ <em>S</em></span></span></p></li>\n<li><p><span><strong>Dependency\nClosure</strong>: <span>∀<em>p</em> ∈ <em>S</em>, <em>p</em> → (<em>n</em>, <em>v</em><em>s</em>) ⟹ ∃(<em>n</em>, <em>v</em>) ∈ <em>S</em> : <em>v</em> ∈ <em>v</em><em>s</em></span></span></p>\n<p><span>If <span><em>p</em></span> is in <span><em>S</em></span> and <span><em>p</em></span> depends on <span>(<em>n</em>, <em>v</em><em>s</em>)</span> then there\nexists a <span>(<em>n</em>, <em>v</em>)</span> in\n<span><em>S</em></span> where <span><em>v</em></span> is in the set <span><em>v</em><em>s</em></span>.</span></p></li>\n<li><p><span><strong>Version\nUniqueness</strong>: <span>∀(<em>n</em>, <em>v</em>), (<em>n</em>, <em>v</em>′) ∈ <em>S</em>, <em>v</em> = <em>v</em>′</span></span></p>\n<p><span>Packages of the same name in <span><em>S</em></span> must have the same\nversion,</span></p></li>\n</ol>\n<p><span>We write <span>𝒮(<em>D</em>, <em>Q</em>)</span> for the set of all\nresolutions of <span><em>Q</em></span> in <span><em>D</em></span>.</span></p></li>\n</ol></li>\n<li><p><span>The Language\n<em>Pac</em></span></p>\n<p><span>Let <span><em>n</em> ∈ <em>N</em></span> and <span><em>v</em> ∈ <em>V</em></span>, then we define the\nexpression language <em>Pac</em> by the following grammar:</span></p>\n<pre><code>p ::= n v vs :== v+ t ::= n ( v+ ) d ::= p ( t^* ) e ::= d^*\n</code></pre>\n<p><span>We extract <span><em>D</em></span> and <span><em>R</em></span> from an expression <span><em>e</em></span> with</span></p>\n<pre><code>d = p ( t^* ) e,m vs t^*, p (m, vs) p R\n</code></pre>\n<ol>\n<li><p><span>Example Mapping from a\n<em>Pak</em> expression to dependencies:</span></p>\n\n\n \n \n <pre>A 1 ( B (1) C (1) )\nB 1 ( D (1 2) )\nC 1 ( D (2 3) )\nD 1 () D 2 () D 3 ()\n </pre>\n \n ⟹\n \n <pre>(A,1) → (B,{1})\n(A,1) → (C,{1})\n(B,1) → (D,{1,2})\n(C,1) → (D,{2,3})\n </pre>\n \n \n \n <em>Grammar expression e</em>\n \n <em>Dependencies relation D</em>\n \n\n\n<p><span>We illustrate this example in figure\n<a href=\"#fig:hypergraph\">1</a> as a directed hypergraph, a graph where\nedges are hyperedges from a package (the domain) to a set of packages\n(the codomain). The hypergraph has vertices <span><em>R</em></span> and hyperedges <span><em>E</em> = {({(<em>n</em>, <em>v</em>)}, {(<em>m</em>, <em>u</em>) ∣ <em>u</em> ∈ <em>v</em><em>s</em>}) ∣ (<em>n</em>, <em>v</em>) → (<em>m</em>, <em>v</em><em>s</em>)}</span>.\nNote that we restrict the domain to a size of one – we can only express\na dependency <em>from</em> one package. The only resolution for the\nquery <span><em>Q</em> = {(<em>A</em>, 1)}</span> is\n<span><em>S</em> = {(<em>A</em>, 1), (<em>B</em>, 1), (<em>C</em>, 1), (<em>D</em>, 2)}</span>.</span></p>\n\n\n\n\n<img src=\"./images/2025-05-19-hypergraph.svg\">\n\nFigure 1: A Resolution Hypergraph\n</li>\n</ol></li>\n</ol>\n<h2>Matrix VoIP</h2>\n<p><span>I’ve <a href=\"https://github.com/RyanGibb/eilean-nix/commit/a4eca30597164f4a9b76dd4b35fc4cd0b808c744\">tried</a>\nand failed to add the new Matrix <a href=\"https://github.com/element-hq/element-call/blob/livekit/docs/self-hosting.md\">Element\nCall stack</a> to <a href=\"eilean.html\">Eilean</a>. I think it’s probably\na misconfigured <a href=\"https://github.com/livekit/livekit\">LiveKit</a>\nturn server.</span></p>\n<h2><a href=\"bigraphs-real-world.html\">Bigraphs of the Real World</a></h2>\n<p><span>I was proof reading the\nlast versions of <a href=\"https://github.com/royangkr/\">Roy</a>’s\nthesis, which was just submitted! I’ve excited to try incorporating some\nof <a href=\"https://github.com/royangkr/bigraph-of-the-world\">his\nwork</a> into <a href=\"eon.html\">Eon</a> as a step towards the <a href=\"spatial-computing.html\">Spatial Name System</a>.</span></p>", 9 "content_type": "html", 10 "categories": [], 11 "source": "https://ryan.freumh.org/atom.xml" 12}