00:51:01 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
00:53:07 <esolangs> [[Smotslang]] M https://esolangs.org/w/index.php?diff=160989&oldid=159895 * Clover-not-used * (-141) not lower
01:20:30 <esolangs> [[Special:Log/newusers]] create * EsolangGUY * New user account
01:39:42 <esolangs> [[User:Pifrited/Simple2DMachine]] https://esolangs.org/w/index.php?diff=160990&oldid=160935 * Pifrited * (-76)
01:57:06 -!- ski has quit (Remote host closed the connection).
02:03:28 <esolangs> [[Extendable MiniLang]] N https://esolangs.org/w/index.php?oldid=160991 * PrySigneToFry * (+4223) Created page with "<blockquote> Next time you create a language that is computable, write an interpreter for it! -- ISLPTNG </blockquote> Extendable MiniLang is designed by PSTF and his AI friend. = Command Set = Can you believe that? It only has 6 commands! {| class="w
02:03:55 <esolangs> [[Extendable MiniLang]] https://esolangs.org/w/index.php?diff=160992&oldid=160991 * PrySigneToFry * (+81)
02:11:06 -!- ski has joined.
03:32:52 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=160993&oldid=159856 * PrySigneToFry * (+593)
05:07:56 <esolangs> [[Qwhy]] https://esolangs.org/w/index.php?diff=160994&oldid=129345 * Stkptr * (+150)
05:08:08 <esolangs> [[Qwhy]] M https://esolangs.org/w/index.php?diff=160995&oldid=160994 * Stkptr * (+2) /* Computational class */
05:47:37 <esolangs> [[User talk:PrySigneToFry]] https://esolangs.org/w/index.php?diff=160996&oldid=160949 * None1 * (+304) /* Any interests on joining our Esolang Tencent QQ group? */
06:38:09 -!- tromp has joined.
07:12:53 -!- Sgeo has quit (Read error: Connection reset by peer).
07:27:16 -!- b_jonas has quit (Quit: leaving).
08:57:21 -!- ais523 has joined.
08:57:36 <ais523> I figured my problem out – I think the thing I have is the ? exponential from linear logic
08:57:48 <ais523> which, if true, would be somewhat major news as I've never seen that thing in a programming language type system before
08:59:14 <ais523> I spent a couple of hours last night just trying to figure out what it even means in a programming language context
09:18:21 <esolangs> [[User:Hotcrystal0/Chess piece strength]] https://esolangs.org/w/index.php?diff=160997&oldid=160929 * PrySigneToFry * (+51)
09:28:16 -!- wib_jonas has joined.
09:28:52 <wib_jonas> ais523: is this related to replacing rust references with something very similar but not quite the same?
09:29:41 <ais523> although it's actually true even for regular Rust references: I think a shared reference is, precisely, a ? of a mutable reference
09:32:23 <ais523> there's a pattern in Rust where basically every function has to be written twice, once with shared references, once with mutable references
09:32:41 <ais523> and I was trying to a) understand why and b) trying to describe the pattern mathematically so that it could be automated
09:32:45 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=160998&oldid=160926 * Creepy * (+21)
09:33:12 <esolangs> [[!Frontal Lobe Lobotomy]] N https://esolangs.org/w/index.php?oldid=160999 * Creepy * (+10074) Created page with "= Frontal Lobe Lobotomy (FLL) = '''Frontal Lobe Lobotomy (1.1.0 COMPILER / 1.2.0 VM => FLL 1.1.0)''' is a '''x86-64''' esoteric programming language inspired by brain surgery metaphors 'Lobotomy'. It uses pointer-addressable neurons and suture levels to r
09:36:45 <wib_jonas> "basically every function has to be written twice" => is this like those C++ functions that index into a collection or dereference an iterator, and can take either a C++ reference or C++ const reference to the collection or iterator and have to return a C++ reference or C++ const reference as the result? \
09:37:45 <ais523> if the only thing you do on a reference is place-project it (which is what those iterators are doing), it's always the case that you get a const and a non-const version with identical code
09:37:46 <wib_jonas> yeah, I've seen a few of those in rust, some functions are even written three times. it didn't bother me too much because it only comes up if you're writing a very generic library with lots of possible use cases.
09:39:17 <esolangs> [[!Frontal Lobe Lobotomy]] https://esolangs.org/w/index.php?diff=161000&oldid=160999 * Creepy * (+246)
09:40:35 <esolangs> [[!Frontal Lobe Lobotomy]] https://esolangs.org/w/index.php?diff=161001&oldid=161000 * Creepy * (+10) /* Download Tooling */
09:41:55 -!- wib_jonas has quit (Quit: Client closed).
09:42:41 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=161002&oldid=160960 * Creepy * (+29)
09:43:12 <ais523> oh, I see, they started the page name with a ! to make it sort near the start of the list
09:44:08 <esolangs> [[Symbolmathing]] https://esolangs.org/w/index.php?diff=161003&oldid=160986 * Bebebe * (+563)
09:45:09 -!- wib_jonas has joined.
09:45:22 <esolangs> [[!Frontal Lobe Lobotomy]] https://esolangs.org/w/index.php?diff=161004&oldid=161001 * Creepy * (+101)
09:45:28 <wib_jonas> there are other cases when rust has a stronger type system with more distinctions than many other languages, and because of this library data types often need extra functions to convert from one type to another. like there's a impl<T, A> Box<[MaybeUninit<T>], A> { unsafe fn assume_init(self) -> Box<[T], A>; } function that compiles to an identity
09:46:36 <esolangs> [[!Frontal Lobe Lobotomy]] https://esolangs.org/w/index.php?diff=161005&oldid=161004 * Creepy * (+6)
09:53:01 <ais523> wib_jonas: yes – in fact recently I've been writing an entire library of things that compile to the identity function
09:53:34 <ais523> at that point they are basically proofs rather than progrms
09:57:58 <wib_jonas> this one isn't a proof because it's unsafe, but there are safe functions like this too, such as impl<T> Cell<[T]> { fn as_slice_of_cells(&self) -> &[Cell<T>]; }
09:59:58 <wib_jonas> though the former one is sort of a proof in the sense that it guarantees an invariant about the representation of Box that an unconventional implementation could technically break, eg. one that may uses a different allocator for the argument and the resturn
10:00:19 <wib_jonas> I mean invokes the allocator with a different layout
10:00:49 -!- wib_jonas has quit (Quit: Client closed).
10:01:00 -!- wib_jonas has joined.
10:03:18 <wib_jonas> eg. you could have a Box implementation that allocates a Box<[T]> into an arena that's usually read-only and made read-write for a short time during the allocation (on cpus that support this) but allocates Box<[MaybeUninit<T>]> into a read-write arena, and the former stores the allocation metadata outside the arena while the latter stores it in
10:03:55 <wib_jonas> it's not something that you're likely to do, but without this function in the library the user wouldn't know that this isn't the case
10:04:11 <esolangs> [[User:Creepy]] N https://esolangs.org/w/index.php?oldid=161006 * Creepy * (+12) Created page with "hi im creepy"
10:05:32 <wib_jonas> admittedly this might not be possible in rust because it would require impl specialization that can detect non-membership in a trait
10:14:34 <ais523> wib_jonas: the representation invariant is actually useful, e.g. Option<T> can have a different representation from Option<MaybeUninit<T>> sometimes, so you need a guarantee that Box doesn't do that
10:18:11 <esolangs> [[Symbolmathing]] https://esolangs.org/w/index.php?diff=161007&oldid=161003 * Bebebe * (+1815) /* Interpreter */
10:18:30 <esolangs> [[Symbolmathing]] https://esolangs.org/w/index.php?diff=161008&oldid=161007 * Bebebe * (-1) /* Interpreter */
10:23:15 -!- amby has joined.
10:25:21 <wib_jonas> by the way I wonder if rust could add built-in types that contain an integer but the range is restricted at compile time, eg. to a union of some intervals. std::num::NonzeroU32 would be a special case of this. and I think it shouldn't be hard to implement this in the compiler because user-defined unit-only enums can do most of what this does. you'd
10:25:21 <wib_jonas> just have to support a range of more values than you could reasonably list in an enum declaration, plus checked and unchecked conversions from the underlying integer type.
10:26:54 <wib_jonas> you could implement this as a user as a wrapper over the base integer type, but a built-in would allow optimizations eg. inside Option or other enums.
10:27:31 <ais523> wib_jonas: https://gist.github.com/joboet/0cecbce925ee2ad1ee3e5520cec81e30
10:28:45 <ais523> apparently hasn't been officially proposed, so it took me a bit longer to find than usual
10:28:51 <ais523> but it's a fairly well-known pre-proposal
10:30:08 <wib_jonas> that one does rather more than what I'm asking for though
10:31:48 <wib_jonas> and I think it's harder to implement
10:32:46 <ais523> I think so – but I think the same sorts of type-system-related problems happen with any refinement type, and also suspect they will need the most implementation effort
10:32:55 <ais523> so doing the rest of pattern types probably isn't too hard once you have integer ranges
10:34:44 -!- Lord_of_Life_ has joined.
10:35:39 -!- Lord_of_Life has quit (Ping timeout: 252 seconds).
10:36:03 <wib_jonas> it's not really the non-integer part that I'm worried there, but that one seems to allow you to implicitly convert a more restricted type to a less restricted one, and more type magic. what I'm proposing would make this an explicit wrapper with conversion functions, except the `as` operator would be used for conversion from restricted to base
10:36:04 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
10:37:17 <esolangs> [[Symbolmathing]] https://esolangs.org/w/index.php?diff=161009&oldid=161008 * Bebebe * (+2478)
10:38:34 <ais523> wib_jonas: the gist has some explanation as to why the conversion is implicit – the basic issue is that an explicit coercion would need to be guarded by a match, but if you have matches perform the coercion automatically and you don't have subtyping then you break all the existing match statements
10:38:52 <ais523> so you'd need to do something like having an attribute on match arms that gets them to refine the type
10:39:35 <wib_jonas> yes, and that could be a useful extension, but I think it's harder to implement it in the specification and compiler
10:43:07 <wib_jonas> at least we have unions now so I can use a struct(i32,union) to represent an enum with extra data in its discriminant, I just can't prove it typesafe
10:45:29 <wib_jonas> I think there was a proposal for C-like bitfields for rust that could handle some of the use cases in a typesafe way, but I don't think it's in the language.
10:50:11 <wib_jonas> it's kind of hard because you have to pack values into the discriminant in a way that you can't make references to them, but rust already has packed structs that do something like that
10:56:19 <ais523> wib_jonas: so I've been thinking about this (I've been thinking about just about everything reference-related)
10:57:35 <ais523> you can make shared references work by having the reference fix the padding/unused bits as it reads (although in that case you can't convert the reference to a memory address because a pointer wouldn't act the same way)
10:58:30 <ais523> and for mutable references, you can mutate the value to fix the padding/unused bits as the reference is formed, then mutate it back when the reference is dropped (although this requires mutable references to have destructors and for the destructors to be guaranteed to run before the lifetime of the mutable reference ends)
10:58:58 <ais523> both of these won't work in current Rust for obvious reasons, but they feel like things that a "fixed" version of Rust would allow
11:07:48 <wib_jonas> but the reference wouldn't be of an ordinary reference type, right?
11:08:12 <wib_jonas> I think rust currently doesn't let you pack three bools into a one-byte struct
11:08:38 <wib_jonas> that's one of those cases that should be possible, you just can't borrow the fields as an ordinary &bool, but you can still read or write them by value
11:09:51 <wib_jonas> "you can mutate the value to fix the padding/unused bits as the reference is formed, then mutate it back when the reference is dropped" hehe, that could work. The shared reference would have to point to a temporary.
11:10:32 <wib_jonas> and I think even that wouldn't work if you like want to shared borrow both the whole structure and the fields
11:10:56 <wib_jonas> but I don't really mind this, these are packed structs and small integer fields, I'm fine with them not being borrowable individually
11:17:44 <ais523> <wib_jonas> but the reference wouldn't be of an ordinary reference type, right? ← so Rust is missing a type that acts like a shared reference, but stores a bitwise copy of the referenced memory rather than the address
11:17:44 <esolangs> [[Mint remake]] N https://esolangs.org/w/index.php?oldid=161010 * Hajunsheng * (+835) Created page with "= Mint remake = Ok, I'll make this quick, it's just mint esolang but remade because the first one didn't work. [https://scratch.mit.edu/projects/1195293853/ visit] = Defining = mint is a variable stack is a stack stuffs is a stack last means last of stack = Comm
11:19:18 <wib_jonas> they didn't manage to add the const-reference-or-value type into C++ yet either
11:19:36 <ais523> I've recently (as in, today) come to the conclusion that Rust should support a type whose representation is "a copy of the referenced object" and whose semantics are "a shared reference except you can't get the address or write cells" and implement shared references as the new type applied to a mutable reference
11:20:02 <ais523> and by "a copy of the referenced object" I mean a bitwise copy, not a type-level copy
11:20:24 <wib_jonas> isn't that what you wanted to write an essay about already?
11:20:38 <ais523> or, well, I want to write several essays and the boundaries between them keep changing
11:21:09 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
11:21:10 <ais523> I've complained for a long time that being able to get the address from a shared reference is wrong
11:21:28 <ais523> but, I've only recently realised just *how* wrong iti s
11:22:00 <wib_jonas> would the mut reference types remain unchanged?
11:22:16 <ais523> the mutable reference types are wrong in a number of ways, but fixing them would break too much code
11:22:25 <ais523> too much existing code, that is
11:22:32 <ais523> so I think they have to be kept around
11:22:48 <ais523> (interestingly, most of the ways in which they're bad don't matter if you treat them as shared references)
11:25:40 <esolangs> [[User talk:PrySigneToFry]] https://esolangs.org/w/index.php?diff=161011&oldid=160996 * Cycwin * (+32) /* Any interests on joining our Esolang Tencent QQ group? */
11:29:48 <ais523> I think the correct way to define a mutable reference type has really different semantics, and &mut is best as syntax sugar / as an efficient way to handle the common case
11:29:52 <esolangs> [[User:Pifrited/Simple2DMachine]] https://esolangs.org/w/index.php?diff=161012&oldid=160990 * Pifrited * (+344)
11:30:26 <int-e> ais523: "address from a reference", you mean (...: &T) as *T?
11:30:29 <ais523> (in particular, I think the reference should "own the value it points to" in the sense that dropping the reference leaves you with an unusable value rather than a readable one)
11:31:51 <int-e> Well the attitude there is that addresses are just bit patterns and uses are unsafe, as far as the Rust compiler is concerned. There's the whole Miri business with an actual memory model that I haven't really looked at though.
11:32:19 <ais523> int-e: yes, but it makes guarantees about things you can do soundly with the resulting references, using unsafe code
11:32:23 <ais523> err, the resulting pointesr
11:36:29 <wib_jonas> int-e: the raw pointer rules have been documented recently, and described in https://doc.rust-lang.org/nightly/std/ptr/index.html#provenance . they also added a few extra functions to handle advanced raw pointer tricks in a way that's neither UB nor prohibits too many optimizations.
11:37:53 <int-e> 'the reference should "own the value it points to"' -- an important use case relies on this not being the case: invoking several fn foo(&mut self) methods in a row
11:37:55 <wib_jonas> these new rules are relevant mostly when you turn a pointer into an integer but later want to turn it back to a pointer.
11:38:53 <int-e> "maybe you want to be able to express fn foo(self), but pass it as a reference because the object is big"?
11:38:59 <ais523> int-e: you need syntax sugar to make that work
11:39:01 <int-e> misplaced the first quite
11:39:09 <wib_jonas> one of the changes that are likely to come up in your code is that if you want an atomic field that stores either a pointer or an integer then you must use AtomicPtr instead of AtomicUsize
11:39:09 <ais523> if references own the value
11:39:14 <ais523> and a few other things too
11:39:25 <int-e> but I don't see how this raises to the level of Rust being *wrong*...
11:40:23 <int-e> wib_jonas: thanks, I felt that I had seen this but forgot the "provenance" keyword so I would never have found it again
11:40:57 <ais523> int-e: although I realised this a while back, I have spent ages thinking about how to argue it convincingly
11:41:42 <wib_jonas> this may be relevant to ais523 because he's the most likely to use atomics this way
11:42:14 <ais523> wib_jonas: I know it already
11:42:23 <ais523> but yes, I was attempting to write that code a while ago
11:42:52 <ais523> that said, strict provenance doesn't work well in code that is operating on smaller-than-pointer-sized references
11:42:57 <int-e> wib_jonas: I don't have full context as usual. You guys are writing a novel.
11:43:13 <ais523> it'd be fine if I could extract the provenances into ZSTs and store them there, but Rust doesn't let you do that, they have to be stored in pointers
11:43:47 <wib_jonas> this makes it hard to use the two pointer sized atomic compare-and-modify of x86, but rust doesn't have a type for that yet
11:44:23 <ais523> I used that as an example of why you might want to use #[repr(align)], when writing a Stack Overflow answer
11:44:51 <ais523> it's a bit of a weird omission because lots of atomic algorithms need to atomically operate on a pointer + a counter
12:02:29 <int-e> ais523: Is this a fair first approximation of what you want? I think you want to separate tracking ownership from addresses (in the form of references) so that you can apply ownership at a finer than byte sized granularity, and also confer ownership through types that don't necessarily contain references?
12:02:45 <ais523> int-e: yes, I think that's a good approximation
12:04:15 <ais523> a mutable reference is effectively a) a guarantee that the referenced data has a particular type, b) an address, c) provenance on the address, d) a way to mutate the data, e) a guarantee of exclusive access to the data, f) a promise to ensure that the referenced data will always have the correct type even if the mutable reference gets unexpectedly dropped
12:04:30 <ais523> and I know for certain that I want to split some of those up, but am not yet sure what the correct split is
12:08:08 <int-e> Nod nod nod... wait, f)?
12:08:37 <ais523> yep – a mutable reference doesn't let you leave the data targeted by the reference in an invalid state, even temporarily
12:08:38 <int-e> (I mean, once all references are dropped the data can be moved or dropped)
12:09:06 <ais523> this is most noticeable in the implementation of drop(), which requires that you leave the thing you're dropping in a valid state, so you can't, e.g., move out of the fields without moving a valid placeholder value in to replace it
12:09:09 <int-e> oh, "always" is short-term intermediate states, not distant future
12:09:39 <int-e> that makes sense then
12:10:20 <ais523> I think the "correct" signature for drop eventually got figured out by the Rust community: it should a) take the value being dropped by value, and b) support a "deconstruction" operation that splits the object into its individual fields, together with a requirement to use it rather than dropping the object normally (which would cause drop to run recursively)
12:11:02 <ais523> deconstruction is not currently supported by Rust for things with destructors, but several people (including me and at least one of the Rust developers) think it should be
12:12:45 <ais523> one nice consequence of that implementation is that dropping becomes a mirror of construction: a constructor does { …; rv = Self { field1, field2, … }; … ; rv } and a destructor is the opposite, |arg| { …; Self { field1, field2, … } = arg; … }
12:14:42 <ais523> there are a few ways to make this sort of thing backwards-compatible, too (although all of them that I'm aware of are a little hacky)
12:16:54 <int-e> Okay, I'll agree that Rust is lacking there. But it might be hard to come up with something that's more expressive, but doesn't require an inordinate amount of boilerplate and/or type annotations. (As an analogy I have this complaint about dependent types... HM types hit a sweet spot where type inference works really well, and you also don't end up with dozens of differently annotated versions...
12:17:00 <int-e> ...of the same type, because such annotations largely don't exist. Now I'm also a fan of some extensions like higher rank types and, ironically, GADTs... but the trick with those is to use them sparingly.)
12:17:16 <lambdabot> int-e says: I want dependable types.
12:19:59 <int-e> There's momentum too; treating references as addresses is a well-trodden path.
12:20:54 <ais523> I think most recently I've been thinking about addresses as something that some types of reference are able to provide, but aren't inherent in the idea of a reference – the ability to provide an address is sort-of like an extra trait that a reference could choose to provide
12:21:22 <ais523> that said, they do seem at least somewhat inherent to references that you can write through, so that you can reason about whether two references are writing the same memory or not
12:22:27 <ais523> but that might not necessarily be the case: you can imagine a "buffered mutable reference" which stores the values being written elsewhere, and only updates the original memory on drop
12:25:19 <int-e> Right that works if you don't have weird things like atomics... well maybe you'd have to completely rethink the "a shared reference conveys mutable access" story for those.
12:25:50 <ais523> the whole linear-logic-? thing that I posted this morning seems to allow for that case
12:26:14 <int-e> (you can't buffer atomics)
12:26:36 <ais523> oh, you can if you have an *exclusive* reference to them
12:26:44 <ais523> it's just shared references that struggle
12:27:07 <ais523> a ?T is like a T except that anything that consumes it has to be prepared to potentially be run as multiple copies, maybe in parallel, while it's consuming the T – in particular this means that it can't while consuming it make use of anything that isn't `Copy`
12:27:22 <int-e> These comments are based on the current treatment of atomics in Rust, with shared references.
12:27:46 <ais523> right, but the "buffered mutable reference" was based specifically on mutable references, so it doesn't interact with atomics
12:28:23 <ais523> anyway, I realised a while back that the current Rust *semantics* of UnsafeCell are that references that point to the outside of the UnsafeCell don't have provenance over the inside
12:28:41 <ais523> not only does the whole API match that, the type-system-level behaviour seems to too
12:29:35 <ais523> you could replace an UnsafeCell<T> with a Box<UnsafeCell<T>> (assuming the box is appropriately-sized), with mutations happening inside the box, and nothing would semantically change
12:35:42 <esolangs> [[User:Tommyaweosme]] https://esolangs.org/w/index.php?diff=161013&oldid=160817 * Tommyaweosme * (+333)
12:38:26 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Sandies]]": unapproved category, doesn't have a clear definition or use case
12:39:03 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Games]]": category redirects don't actually work correctly, so they shouldn't be made
12:39:28 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Commands]]": apparently created in error, but wasn't deleted until now
12:39:54 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Themed]]": unapproved category, redundant to existing [[Category:Thematic]]
12:48:18 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=161014&oldid=158199 * Ais523 * (+16) /* T */ +[[Turn Left]]: it has an interpreter now
12:49:28 -!- chiselfuse has quit (Remote host closed the connection).
12:49:44 -!- chiselfuse has joined.
12:58:26 <HackEso> [U+214B TURNED AMPERSAND]
13:05:27 -!- wib_jonas has quit (Quit: Client closed).
13:10:02 <esolangs> [[User:Pifrited/Simple2DMachine]] M https://esolangs.org/w/index.php?diff=161015&oldid=161012 * Pifrited * (-9) /* Commands */
13:11:58 -!- tromp has joined.
13:19:11 <esolangs> [[User talk:Pifrited/Simple2DMachine]] https://esolangs.org/w/index.php?diff=161016&oldid=160933 * Pifrited * (+197)
13:19:33 <esolangs> [[User talk:Pifrited/Simple2DMachine]] M https://esolangs.org/w/index.php?diff=161017&oldid=161016 * Pifrited * (+1)
13:40:44 -!- wib_jonas has joined.
13:43:18 <wib_jonas> ais523: but what happens when the type that the reference points to has interior mutability like an UnsafeCell field? you can't use a bitwise copy for that instead of the original one.
13:48:07 <int-e> But conceptually, given a mutable reference, you can move the value out, modify it, and move it back in. Unless the object is pinned.
13:49:07 <int-e> Operationally that move can be done by making a copy and relying on the fact that nobody can touch the original.
13:49:41 <int-e> The thing that you break is that the mutable reference stops pointing to a valid object (it becomes stale) while you're working with the copy.
13:50:34 <int-e> ("thing" - a guarantee that Rust currently has. Well, I'm taking ais523's word for that.)
13:58:48 <int-e> wib_jonas: totally unrelated, I've started actually toying with the wire things in shapez 2 and there's a huge change in how signals are propagated. It's no longer feeding the old wire states into the components and combining the outputs on the connected wires each tick; signals propagate much further in a single tick. Which breaks my shapez 1 edge triggers. OTOH a not gate feeding into itself...
13:58:54 <int-e> ...will still flicker, so maybe signal propagation stops when it comes a full circle. Details are unclear to me. Maybe every logic gate is updated at most once per tick?
14:00:51 <wib_jonas> int-e: I was thinking of such a system for a hypothetical game, but in a way that explicitly allows you to introduce delays
14:01:00 <int-e> On the plus side, my not+transistor+or RS-flip-flop still works. Which coupled with a clock should be enough to bootstrap clocked circuits.
14:01:40 <int-e> yeah a D flip-flop would be helpful
14:01:42 <wib_jonas> is there no explicit memory cell or delay or similar object?
14:02:31 <int-e> I have all the research. The only explicit delay I've found is the global communication, which has a half second delay or so.
14:02:31 -!- ais523 has quit (Quit: sorry about my connection).
14:03:53 <int-e> Anyway. It's a change. There's an up-side to it too, obviously; deeper circuits are no longer slow.
14:04:15 <int-e> I'll keep experimenting.
14:04:56 <int-e> a transistor feeding into itself will still keep a value alive at least.
14:05:13 -!- ais523 has joined.
14:05:44 <wib_jonas> do transistors consistently add a delay, eg. for just the control input?
14:05:58 <ais523> <wib_jonas> ais523: but what happens when the type that the reference points to has interior mutability like an UnsafeCell field? you can't use a bitwise copy for that instead of the original one. ← indeed, writing to a cell needs the address
14:06:16 <int-e> (tried that. that was my (and I suppose everybody else's) default delay in shapez 1 after all)
14:06:30 <ais523> it conceptually works because the data inside the cell isn't part of the copy – it's referenced by the copy – but doesn't physically work because the computer doesn't know where the cell actually is
14:06:38 <wib_jonas> ais523: reading from the cell needs the address too, if you don't exclusively own the cell
14:18:07 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=161018&oldid=161002 * PrySigneToFry * (+26)
14:41:49 <int-e> wib_jonas: Oh no! The order in which you place the gates matters now. And pasting blueprints doesn't preserve it.
14:43:23 <int-e> though you can tweak the order in which buildings are in the blueprint by changing its orientation when you create the blueprint
14:43:32 <int-e> this might not be fun.
14:44:37 <wib_jonas> in games like this you often can't really make the rules symmetric to all the reasonable symmetries in all cases
14:45:01 <int-e> right but shapez 1 was an exception as far as the wire layer was concerned
14:45:21 <wib_jonas> but ideally you want to make it not matter too much for the player, at least if the player keeps certain rules that don't restrict them too much
14:46:25 <int-e> huh I wonder whether loading and saving breaks this too then
14:54:54 <int-e> well saving and loading certainly changes something
14:58:39 <int-e> https://int-e.eu/~bf3/tmp/shapez2-wire-trouble.jpg -- this is after saving and loading; the left variant started out as a copy of the right one. 5 work fine (one can store a provided value in the single transistor loop) but for the other three it doesn't work.
14:59:27 <ais523> I tried the shapez 1 demo but didn't enjoy it
14:59:48 <ais523> in general, that sort of game seems like it would be more interesting if you do the computation with the same pieces that you make the shapes out of, rather than having an entire separate system
15:00:38 <int-e> I think what changes is the order in which the not gate and the two transistors are evaluated, and I currently conjecture that the update process starts with a changed signal and propagates changes from there, but only ever updating any gate once.
15:01:54 <int-e> Not because I can confirm it experimentally but because it's a plausible implementation. I could maybe check whether DAGs update consistently in a single cycle.
15:05:11 <wib_jonas> ais523: in the demo, did you reach the two puzzles, which is how to make the last two upgrade shapes? because that's I think one of the interesting parts of this game.
15:05:12 <int-e> ais523: Eh it's not primarly a model of computation. It's support for automation, with the specific goal that the game can request a shape and there's enough logic to disect it and guide production accordingly.
15:06:03 <int-e> (Does the demo even have the wire layer? I forgot.)
15:09:09 <wib_jonas> int-e: the new version of the demo definitely doesn't; I think the old version doesn't either but I don't remember for sure how far it goes
15:09:16 -!- wib_jonas has quit (Quit: Client closed).
15:12:02 <int-e> I really don't think of shapez (1 or 2) as a programming game. Obviously there are aspects to it that appeal to programmers... making modular reusable designs, mostly. And there's a strong golfing component to it too if you're so inclined. But then it's a sequence of puzzles, figuring out recipes to make certain shapes. And finally using the wire layer for automation, and then the only thing...
15:12:08 <int-e> ...that's left is either tinkering with those things endlessly or making up your own tasks in a sandbox.
15:18:48 <int-e> ais523: also maybe I misunderstood... the wire layer absolutely can simulate the production part; it's not just 0s and 1s, wires can carry (virtual) shapes.
15:19:49 <int-e> I'm just not playing with that right now because I'm more worried about state management / control flow.
15:22:22 <int-e> And sure, you could restrict the wires to only have shapes, but you'd probably not change it significantly; you'd want to encode a conditional somewhere, and in a non-esoteric fashion because making it complicated would reduce your audience to a dozen people who enjoy this kind of thing and play the game. :P
15:23:45 <int-e> (I've seen people struggle with the wire layer as it is, with its very mundane logic signaling part.)
15:24:02 <int-e> Anyway. You dislike it and that's okay :-P
15:25:59 <ais523> int-e: I was thinking more of using the production part to simulate the wire layer
15:26:20 <ais523> like, having machines that turn on and off based on whether you paint them red or blue, that sort of thing
15:27:04 <esolangs> [[User:Aadenboy]] M https://esolangs.org/w/index.php?diff=161019&oldid=160982 * Aadenboy * (+19) /* VSCode Box Drawing */ I got a review!
15:28:28 <esolangs> [[Semi-serious language list]] https://esolangs.org/w/index.php?diff=161020&oldid=161014 * PkmnQ * (+60) Add a few queue-based languages (may add more later)
15:28:52 <int-e> ais523: yeah that would be a completely different type of game
15:30:18 <ais523> it seems so superflous to have two different types of thing (wire signals and manufacturing components) when one would do
15:31:30 <ais523> I guess the extreme version of this viewpoint would be to be able to put machine components on the belts (including belts) so that your machine could manufacture itself
15:31:59 <ais523> and create a make-anything-machine that handles all the tasks it's ever been given simultaneously, rather than switching from one goal to the next
15:43:24 <int-e> I /think/ the wire stuff does a topological sort (but breaking loops in an unpredictable way, well, unpredictable to me)
15:43:39 <ais523> it might be arbitrary, I guess?
15:43:56 <ais523> based on something like iteration order over a hash table
15:44:00 <ais523> that's what tsorts do by "default"
15:44:30 <esolangs> [[User:Hotcrystal0/Chess piece strength]] https://esolangs.org/w/index.php?diff=161021&oldid=160997 * Hotcrystal0 * (+17)
15:46:27 <int-e> Hmm, no, that isn't right. Under that theory my basic memory cell should work fine.
15:52:13 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:04:59 <esolangs> [[Talk:YOUR TAKING TOO LONG]] N https://esolangs.org/w/index.php?oldid=161022 * PlaceReporter99 * (+151) Created page with "So this is just a derivative of [[bf]]? ~~~~"
16:22:42 -!- tromp has joined.
16:29:56 -!- b_jonas has joined.
16:34:54 <b_jonas> ais523: people have used Factorio belts (and splitters and undergrounds, but without circuit signals or other tricks) to simulate arbitrary logic circuit. this is rather inefficient and so esoteric. I'm not sure how hard it would be in shapez.io 1, because shapez.io 1 doesn't have convenient priority merges. but this uses only where the items are on the belt rather than where they are. for shapez 1, if
16:35:00 <b_jonas> you want to add new builtins to make it easier to use the belts for computation, you have to be careful that they don't cook shapez1's puzzles or make the game too much easier. .
16:35:52 <ais523> I guess I considered the puzzles I saw sufficiently easy to not consider them to add to the game
16:36:29 <ais523> I am not sure whether I saw all of them or not
16:36:37 <b_jonas> in my head the idea is that logic computation should be free, but producing specific shapes on belts, especially in large numbers quickly, is the task that you need to solve, and so shouldn't be free.
16:37:01 <int-e> ais523: there's really only two of those fixed level shapes that stump people, both variations on the same idea
16:37:37 <ais523> the existence of an MAM also implies the existence of a simple algorithm for constructing any given shape
16:38:24 <int-e> one is https://viewer.shapez.io/?RuCw--Cw:----Ru-- and the other one is https://viewer.shapez.io/?CbCuCbCu:Sr------:--CrSrCr:CwCwCwCw and both feature things that aren't directly supported from below.
16:38:38 <b_jonas> ais523: that's why I'm asking if you produced the last two upgrade shapes, https://viewer.shapez.io/?RuCw--Cw:----Ru-- and https://viewer.shapez.io/?CbCuCbCu:Sr------:--CrSrCr:CwCwCwCw . these are puzzles where you have to experiment to learn what exactly the rules for the cutter and stacker are, and then figure out how to use them to build those shapes, especially in large numbers without manual
16:38:47 <int-e> the rest of the game up to the MAM stage is just building
16:39:06 <b_jonas> these are also level goal shapes, but those levels aren't in the demo, only the upgrades are.
16:39:28 <int-e> oh I had not considered that you could still go for all those upgrades in the demo
16:39:31 <ais523> OK, so the challenge in the first one is to construct the higher-level corner without it falling down?
16:39:33 <int-e> and find the shapes that way
16:40:42 <ais523> ah, I think in that case the puzzle is understanding what the game mechanics are – I expect the solution to be simple but not necessarily easy to find as you might have to determine the mechanics by experiment
16:40:52 <b_jonas> int-e: I realized that back when I recommended the game to tom7, because he makes the kind of puzzles where you have to experiment to learn the rules.
16:41:28 <ais523> I wouldn't expect variations to the game to break the puzzle, in that case
16:43:29 <ais523> not having the game open or really remembering the rules, I would guess that the solution would be something like "create a shape with an arbitrary nonempty right half at the lowest level, a white quarter-circle in the top-left and nothing in the bottom-left; stack the bottom half of a gray square on it; then cut off the right half and replace it with the correct right half"
16:44:00 <ais523> as that's the sort of solution for which I can imagine rules where that's the simplest solution, whereas most rules I'm considering make it either trivial or impossible
16:45:40 <b_jonas> as for "to be able to put machine components on the belts (including belts) so that your machine could manufacture itself" => that's what Factorio does. Factorio has the severe restriction that almost any building has to be constructed using one type of item (usually just one instance of the item but that's not strict), rather than assembled in place at construction time from multiple types of items.
16:45:46 <b_jonas> that's mostly to make the vanilla game an interesting challenge and simple, but it sort of hurts modded variants. if you want to construct buildings from multiple types of items then you have to play Settlers.
16:47:34 <int-e> ais523: I did get some entertainment out of the puzzle mode dlc, which focusses on finding recipes and golfing. (Puzzles are crowd-sourced, but there's a reasonably functional difficulty assessment that looks at how many people who try a puzzle actually solve it and maybe also at the time taken.)
16:47:56 <int-e> they inevitably suffer from overused themes of course
16:48:26 <b_jonas> "difficulty assessment that looks at how many people who try a puzzle actually solve it and maybe also at the time taken." => ah, the Mario Maker difficulty system
16:49:03 <int-e> one such theme is... people have figured out that you can encode number link with just producers, goals, and belts, disallowing everything else, so there's a *ton* of number link puzzles in there.
16:54:37 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:59:38 <b_jonas> I'll also remark that for me personally, shapez 1 was the first conveyor belt factory game that I playes, as such it's a gateway drug into Factorio. and since shapez 1 has a definite goal that you can reach in a not too long playtime, it works as such a gateway drug for other players too.
17:07:43 -!- tromp has joined.
17:45:30 <zzo38> About puzzles that you will have to experiment to figure out the rules, for games that include the source codes the way would be to examine the source codes to figure out the rules.
17:46:44 -!- shikhin has quit (Quit: Quittin'.).
17:48:30 -!- shikhin has joined.
17:49:48 -!- shikhin has changed hostmask to ~shikhin@offtopia/offtopian.
17:51:59 <zzo38> In the case of some Hero Hearts puzzles (e.g. SUPERHRO:384-403), it says there are tricks that you will have to work hard to discover, and also objects hidden behind other objects. The original game engine is not FOSS but the source code for the implementations of the classes is available (actually they are stored as P-code and decompiled when you want to edit them).
17:52:29 <zzo38> So, sometimes behaviours (including unintended consequences of them) can be found from examining these codes.
17:57:38 <zzo38> The documentation does have some details about the internal working of the game engine, but I have found it to be incomplete and incorrect in many ways. I have made experiments to figure out the actual working and reimplemented it, now as FOSS, so that now the rules can actually be read and figured out that way.
18:03:10 <b_jonas> zzo38: yes, and I did eventually examine the source code of shapez.io to learn how freeplay shapez are rolled, and later the rules for stacking too.
18:05:41 <zzo38> (I also implemented the ability to right-click on a grid cell to display a list of all of the objects in that grid cell, so that it is a game of complete information.)
18:25:16 -!- ais523 has quit (Quit: quit).
19:33:02 <korvo> ais523: Regarding linear logic: we can quickly check whether a modality is one of the two canonical exponentials by asking if they satisfy universal laws. For the ? modality, the relevant law is that it's a monad; X o- ?X and ??X o- ?X naturally for any X.
19:33:44 <korvo> So a shared ref of a shared ref would still be a shared ref. Seems plausible. Indeed, this seems like something that would have arisen in the literature already, although most folks study ! instead since ! is required for the intuitionistic-linear bridge.
19:35:22 <korvo> Oh, those lollys should be the other way around, X -o ?X and ??X -o ?X. Whoops.
20:32:35 <esolangs> [[Ougsoeei]] N https://esolangs.org/w/index.php?oldid=161023 * Bebebe * (+221) Created page with "{{infobox proglang |name=Ougsoeei |author=[[User:bebebe]] |year=2025 }} {{wip}} Ougsoeei is from [[User: bebebe]](this is a nickname). bebebe's goal was to create a highly illogical and inconsistent esolang for people."
20:47:46 <esolangs> [[Qdeql]] https://esolangs.org/w/index.php?diff=161024&oldid=53701 * Stkptr * (+20)
20:47:56 <esolangs> [[Queuenanimous]] https://esolangs.org/w/index.php?diff=161025&oldid=156777 * Stkptr * (+12)
21:22:45 <esolangs> [[Main Page]] https://esolangs.org/w/index.php?diff=161026&oldid=155804 * Bebebe * (+2)
21:23:31 <esolangs> [[Main Page]] https://esolangs.org/w/index.php?diff=161027&oldid=161026 * Bebebe * (-2)
21:29:50 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:30:33 <esolangs> [[Ougsoeei]] https://esolangs.org/w/index.php?diff=161028&oldid=161023 * Bebebe * (-184)
21:43:10 <esolangs> [[Special:Log/newusers]] create * Dmitry samorodyuk * New user account
22:04:38 -!- Sgeo has joined.
22:29:22 -!- janewila has joined.
22:45:21 -!- janewila has quit (Quit: Client closed).
23:12:57 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).