nullagent boosted
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
nullagent
@nullagent@partyon.xyz  ·  activity timestamp 6 days ago
screwlisp
@screwlisp@gamerplus.org  ·  activity timestamp last week
My NicCLIM McCLIM map again; but I added pictures, in which I basically replaced LEFT with a squiggly cursive left, right similarly, left2rite similarly. Except I used white in left2right, so I put the unix_surrealism penguin behind it in the map for contrast.
An animation of the NicCLIM from earlier: but the too-wide map has been replaced with a fits-nicely-grid, in which a radio choice pops up, allowing the player @ to travel to 'the right half' map.
no images... About 11 columns of a "hexagonal" arrangement of boxes on the right half of a common lisp interface manager user interface, with the left having an interactor and several informational boxes. It is my NicCLIM, which is basically just McCLIM as such.
no images... About 11 columns of a "hexagonal" arrangement of boxes on the right half of a common lisp interface manager user interface, with the left having an interactor and several informational boxes. It is my NicCLIM, which is basically just McCLIM as such.
no images... About 11 columns of a "hexagonal" arrangement of boxes on the right half of a common lisp interface manager user interface, with the left having an interactor and several informational boxes. It is my NicCLIM, which is basically just McCLIM as such.
phildini boosted
Corv
@corv@social.tchncs.de  ·  activity timestamp 2 weeks ago
LM Studio running Qwen3-Coder using Shannot to check disk space on Linux
Corv
@corv@social.tchncs.de  ·  activity timestamp 2 weeks ago
LM Studio running Qwen3-Coder using Shannot to check disk space on Linux
screwlisp
@screwlisp@gamerplus.org  ·  activity timestamp 2 months ago
NicCLIM map editor; a Common lisp interface manager 2.0 application frame. The right half is filled with blue and green rectangular tiles, with yellow and pinkish-red overlaid on a few of them. The left half is more of a dashboard, with x=4, y=5, has (EMPTY LIFE), cur1=NIL, cur2=NIL, and an interactor waiting for a Command: . The menu bar across the top has: bitmap, cursor, mov, addrem, layouts:, Rect!, lisp, macro and player.
NicCLIM map editor; a Common lisp interface manager 2.0 application frame. The right half is filled with blue and green rectangular tiles, with yellow and pinkish-red overlaid on a few of them. The left half is more of a dashboard, with x=4, y=5, has (EMPTY LIFE), cur1=NIL, cur2=NIL, and an interactor waiting for a Command: . The menu bar across the top has: bitmap, cursor, mov, addrem, layouts:, Rect!, lisp, macro and player.
NicCLIM map editor; a Common lisp interface manager 2.0 application frame. The right half is filled with blue and green rectangular tiles, with yellow and pinkish-red overlaid on a few of them. The left half is more of a dashboard, with x=4, y=5, has (EMPTY LIFE), cur1=NIL, cur2=NIL, and an interactor waiting for a Command: . The menu bar across the top has: bitmap, cursor, mov, addrem, layouts:, Rect!, lisp, macro and player.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
## relations as first-class objects logically, all relations could be collated into a single relation of polymorphic variadic type, where the relation itself becomes the first argument, i.e. `rel(x,...)` becomes `(rel,x,...)`. this then makes it possible to e.g. match all relations that contain a specific value in a specific column, or to enumerate all relations that exist in the program, or to interrogate the program. it would also permit dynamic creation of new relations at runtime, although more properties are required to capture every aspect of a relation. to begin with, what is the arity of a relation? this, too, is an arbitrary constraint. the "super relation" as i would call it also hosts every virtual relation, and thus likely has cosmic proportions, so can not be naively enumerated.
## relations as first-class objects logically, all relations could be collated into a single relation of polymorphic variadic type, where the relation itself becomes the first argument, i.e. `rel(x,...)` becomes `(rel,x,...)`. this then makes it possible to e.g. match all relations that contain a specific value in a specific column, or to enumerate all relations that exist in the program, or to interrogate the program. it would also permit dynamic creation of new relations at runtime, although more properties are required to capture every aspect of a relation. to begin with, what is the arity of a relation? this, too, is an arbitrary constraint. the "super relation" as i would call it also hosts every virtual relation, and thus likely has cosmic proportions, so can not be naively enumerated.
## relations as first-class objects logically, all relations could be collated into a single relation of polymorphic variadic type, where the relation itself becomes the first argument, i.e. `rel(x,...)` becomes `(rel,x,...)`. this then makes it possible to e.g. match all relations that contain a specific value in a specific column, or to enumerate all relations that exist in the program, or to interrogate the program. it would also permit dynamic creation of new relations at runtime, although more properties are required to capture every aspect of a relation. to begin with, what is the arity of a relation? this, too, is an arbitrary constraint. the "super relation" as i would call it also hosts every virtual relation, and thus likely has cosmic proportions, so can not be naively enumerated.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
## incremental deletion when the insertion of a value depends on the non-presence of another (contained in a negated relation), then that means for insertions into a negated relation, existing facts must be removed if they can not be backed by any other rule. take for instance `C(x) :- A(x), !B(x).` which subtracts set B from set A. this is equivalent to `!C(x) :- !A(x). !C(x) :- B(x).`, which could be called deletion rules. simply put, `Y(x) :- X(x). Y(x) :- Z(x).`, without any further disjunctive rules, implies `!Y(x) :- !X(x),!Z(x).`, and in a "convex" set this can be ignored, but if `!X` and `!Z` conclusions exist, then `!Y` conclusions must also be realized. all this gives us clear logical paths to follow and thus seems reasonable to me, if only it is unclear how to implement this efficiently.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
# will produce following topological order and lifetimes: --------------- rel_order =============== 0 i 1 b 1 a 2 c 2 d 3 o =============== --------------- rel_lt =============== 1 i 2 b 2 a 3 o 3 c 3 d =============== struct i (x : s32) struct a (x : s32) struct b (x : s32) struct c (x : s32) struct d (x : s32) struct o (x : s32) a x if (i x) a x if (b x) b x if (a x) c x if (b x) d x if (c x) c x if (d x) o x if (d x)
# will produce following topological order and lifetimes: --------------- rel_order =============== 0 i 1 b 1 a 2 c 2 d 3 o =============== --------------- rel_lt =============== 1 i 2 b 2 a 3 o 3 c 3 d =============== struct i (x : s32) struct a (x : s32) struct b (x : s32) struct c (x : s32) struct d (x : s32) struct o (x : s32) a x if (i x) a x if (b x) b x if (a x) c x if (b x) d x if (c x) c x if (d x) o x if (d x)
# will produce following topological order and lifetimes: --------------- rel_order =============== 0 i 1 b 1 a 2 c 2 d 3 o =============== --------------- rel_lt =============== 1 i 2 b 2 a 3 o 3 c 3 d =============== struct i (x : s32) struct a (x : s32) struct b (x : s32) struct c (x : s32) struct d (x : s32) struct o (x : s32) a x if (i x) a x if (b x) b x if (a x) c x if (b x) d x if (c x) c x if (d x) o x if (d x)
// topological order of relations .decl rel_order(n:number, rel:symbol) rel_order(i,rel) :- Rel(rel), scc(scc_id, rel), scc_order(i, scc_id). // relation lifetime (after which order can we free this relation) .decl rel_lt(n:number, rel:symbol) rel_lt(i,rel) :- Rel(rel), scc(scc_id, rel), !scc_dep(_, scc_id), scc_order(i, scc_id). rel_lt(mxi,rel) :- Rel(rel), scc(scc_id, rel), scc_dep(scc_user, scc_id), mxi = max i : { scc_order(i, scc_user) }.
// topological order of relations .decl rel_order(n:number, rel:symbol) rel_order(i,rel) :- Rel(rel), scc(scc_id, rel), scc_order(i, scc_id). // relation lifetime (after which order can we free this relation) .decl rel_lt(n:number, rel:symbol) rel_lt(i,rel) :- Rel(rel), scc(scc_id, rel), !scc_dep(_, scc_id), scc_order(i, scc_id). rel_lt(mxi,rel) :- Rel(rel), scc(scc_id, rel), scc_dep(scc_user, scc_id), mxi = max i : { scc_order(i, scc_user) }.
// topological order of relations .decl rel_order(n:number, rel:symbol) rel_order(i,rel) :- Rel(rel), scc(scc_id, rel), scc_order(i, scc_id). // relation lifetime (after which order can we free this relation) .decl rel_lt(n:number, rel:symbol) rel_lt(i,rel) :- Rel(rel), scc(scc_id, rel), !scc_dep(_, scc_id), scc_order(i, scc_id). rel_lt(mxi,rel) :- Rel(rel), scc(scc_id, rel), scc_dep(scc_user, scc_id), mxi = max i : { scc_order(i, scc_user) }.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
.decl scc_dep(scc:number, src:number) // SCC dependency edges scc_dep(scc_a, scc_b) :- rel_dep(a, b), scc(scc_a, a), scc(scc_b, b), scc_a != scc_b. // SCC transitive closure .decl scc_dep_tc(scc:number, src:number, dist:number) scc_dep_tc(a, b, 1) :- scc_dep(a, b). scc_dep_tc(a, c, ab + bc) :- scc_dep_tc(a, b, ab), scc_dep_tc(b, c, bc). // topological order of SCC .decl scc_order(index:number, scc:number) scc_order(0, a) :- scc(a, _), !scc_dep(a, _). scc_order(mxi, a) :- scc(a, _), mxi = max i : { scc_dep_tc(a, _, i) }.
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
Leonard Ritter
@lritter@mastodon.gamedev.place  ·  activity timestamp 2 months ago
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
.decl rel_cy(rel:symbol, src:symbol) // transitive closure of cyclical edges rel_cy(a, b) :- rel_dep(a,b), rel_dep_tc(b,a). rel_cy(a, c) :- rel_cy(a, b), rel_cy(b, c). .decl scc(group:number, rel:symbol) // strongly connected components scc(mnx, y) :- rel_cy(_, y), rel_id(y_id, y), mnx = min x_id : { rel_cy(x, y), rel_id(x_id, x), x_id <= y_id }.
Home Login