00:02:23 -!- mtm has quit (Ping timeout: 255 seconds).
00:06:03 -!- mtm has joined.
00:43:18 -!- troojg has joined.
01:14:11 -!- 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).
01:19:01 -!- unjust has joined.
01:29:28 <b_jonas> ais523: I haven't read it yet, but the relevant RFC is https://github.com/rust-lang/rfcs/blob/master/text/1909-unsized-rvalues.md which is partly implemented as an unstable feature in the compiler as https://doc.rust-lang.org/nightly/unstable-book/language-features/unsized-locals.html https://doc.rust-lang.org/nightly/unstable-book/language-features/unsized-fn-params.html
01:51:40 <ais523> my idea's a bit different – basically it's to have scoped constants that are only constant in a particular scope, and everything depending on them is lifetime-limited to that scope
01:52:44 <ais523> most of the proposal is pretty easy to implement, but generalising it to also be usable for array sizes isn't
01:55:43 <b_jonas> ais523: yes, that's rather more complicated, I'm just linking this because it's about copying VLAs
01:56:15 -!- troojg has quit (Ping timeout: 276 seconds).
02:06:46 <b_jonas> as for “‘better enough’ than C”, I consider Rust as a better enough than C++, meanwhile zig is the possibly better enough than C language. The distinction is obvious enough: rust has types that have a destructor that is ran automatically when a variable goes out of scope, while zig explicitly does not want to have those.
02:08:15 -!- unjust has left.
02:10:12 <esolangs> [[Collab]] https://esolangs.org/w/index.php?diff=136863&oldid=136850 * PkmnQ * (+308) /* Commands */ Control flow time
02:17:10 <b_jonas> “memory wasted storing the same values repetitively, […] either requiring runtime checks [of consistency] even though that should be possible to determine at compile time” => that's probably one of those big unsolvable problems of programming, where even ten years from now we'll have a lot of practical cases that we can't prove to any compiler
02:19:27 <b_jonas> I even have a mild case of it in the polyform enumerating program that I'm developing, where I know that all the polyforms in a large array have the same number of blocks, and the rest of the array representing it is zeroed out, but I can't really prove that to the compiler.
02:19:55 <ais523> well, the easy cases are a) solvable but b) unsolved in Rust currently, and probably lots of other languages too
02:20:08 <ais523> I agree that there are probably some unsolvable hard cases
02:25:29 <ais523> <b_jonas> as for “‘better enough’ than C”, I consider Rust as a better enough than C++, meanwhile zig is the possibly better enough than C language. The distinction is obvious enough: rust has types that have a destructor that is ran automatically when a variable goes out of scope, while zig explicitly does not want to have those. ← Rust's implementation of Drop is a mistake, possibly in more than one way
02:25:51 -!- bookworms has joined.
02:26:01 <ais523> but I think the correct solution is along the lines of "explicit destructors but the compiler verifies that you run them, and failing to destroy an object without an explicit mem::forget or the like is a compile error"
02:26:10 <ais523> and it's unclear whether that's closer to C or C++
02:26:25 <ais523> in any case, Rust can be better enough than C despite being dissimilar to it
02:26:41 <b_jonas> I don't see why that would be
02:27:25 <b_jonas> would you like people to write some explicit markup in the program for local variable where you have to run the destructor at the end of the scope?
02:27:26 <ais523> fwiw, I consider C a better language than C++, and many of the things I dislike about Rust are places where it copied C++
02:27:39 <ais523> b_jonas: if it has a destructor, yes, apart from Rc variants
02:28:19 <b_jonas> that sounds like you want zig
02:28:41 <ais523> no, I want Rust with Zig-style destructors
02:28:43 <b_jonas> not that I want to talk you into it, I like rust and its destructors
02:29:55 <ais523> or, well, I guess the way I'd put it is that I think destructors that have side effects beyond pure memory management are better explicit, because a) the program flow is obscured otherwise and b) often they want to take parameters, in which case the call would have to be explicit
02:30:35 <ais523> also, I think that destructors that just manage memory are inherently different from other sorts of destructor, and behave more like a garbage collector than, say, a destructor that closes a file
02:33:20 <ais523> I guess the way I'd put it is, from a semantic point of view ignoring performance, often the clearest code would be produced by a mechanism in which the program behaviour is the same as if it were working entirely by-value, cloning an objects whenever you passed it to a function or method
02:34:17 <ais523> and a significant number of features in a range of languages – borrows, Rc, garbage collectors – exist to try to emulate that behaviour, but with better performance (which they gain by not supporting the entire range of possible cases)
02:34:35 <ais523> destructors can be part of that, and if they're used for that it's fine for them to be implicit
02:35:40 <b_jonas> sure, that's how the C++ standard library containers started out, they all copy deeply by default
02:36:05 <ais523> but, for the type of object that has an identity, is mutable, etc., destroying it has semantic meaning and should generally be done intentionally, rather than with automatically determined timings like "when the last reference is gone" (and in fact, it's often semantically correct for it to be destroyed while there are still references, breaking the references)
02:36:52 <ais523> e.g. in NetHack, conceptually you want to destroy the object representing a monster when the monster dies, even though there are likely to still be existing references to it at that pointn
02:37:41 <zzo38> I just use C, even though there are some problems with it, Rust and Zig have their own different problems, I think.
02:37:44 <ais523> and it uses a method of simulating weak references to make it work, using the DEADMONSTER flag
02:38:21 <ais523> (there's a bug in 3.4.3 you can exploit to set the DEADMONSTER flag on the player, which leads to some interesting consequences)
02:38:40 <zzo38> (I also think that different programming languages can be good for different purposes, too)
02:38:50 <b_jonas> sure, but you can do such explicit destruction in any language that implements weak references, and you can implement all sorts of variants of that in rust, either the one in the standard library or other solutions
02:39:42 <b_jonas> it gets even funnier in M:tG where effects can reference objects after the object is dead (usually because it's moved away from the zone or because it was a token or copy of a spell that the SBA destroyed because it's in the wrong zone)
02:40:43 <ais523> right – but I basically see the world of objects as being "pure value-like things that you can put directly into an Rc without issue" and "things that need to be destroyed explicitly", and that doesn't leave much room for useful Drop-style autodestructors other than those concerned purely with memory management
02:41:33 <ais523> zzo38: I agree about different languages being useful for different purposes; I still use languages like Perl and Makefile when appropriate, even though I think neither would be a good idea for a large project
02:44:39 <b_jonas> how about values like std::cell::Ref or std::sync::MutexGuard, where the drop has more side effects than just pure memory management, and, in the latter case, could even call a syscall in the contented case, but the effect is conceptually still localized to the process's internal state, unlike eg. closing a file descriptor or some other object that has high side effects on closing?
02:45:37 <ais523> dropping a MutexGuard feels like it needs to be explicit because the timing matters – in many cases you want to drop it earlier than the end of the scope
02:46:57 <b_jonas> yes, luckily rust lets you just destroy any local variable earlier than when it would naturally go out of its lexical scope, so that's easier than C++
02:47:37 <ais523> it seems overly complicated to call `drop`, which then calls the destructor via a trait, rather than just simply calling the destructor directly
02:47:55 <b_jonas> though of course for the fully general case where you can destroy it from called functions you would need to wrap it in an Option that you pass by mut reference
02:48:41 <ais523> fwiw, I normally use Cell rather than RefCell, and swap a placeholder value into the cell if I need to reference it
02:49:09 <ais523> with that implementation, the way you "drop the reference" is to swap a value back, i.e. to write to the cell
02:49:12 <b_jonas> ais523: but you need that for the invariant guarantees where the existence of a MutexGuard guarantees that you have the lock. if you don't want that invariant then you use an Option<MutexGuard>, or, if you don't want to prove safety to the compiler, a ManuallyDrop<MutexGuard>
02:49:18 <ais523> so it feels inherently like dropping a Ref is a write operation that should take an argument
02:49:47 <b_jonas> sure, Cell has its place and it's often worth to use it, but sometimes you do want a RefCell
02:50:11 <b_jonas> I'm using both in the same program
02:50:34 <ais523> b_jonas: no you don't, the existence still guarantees you have a lock even if you drop the lock via using an inherent method that takes `self` as a parameter
02:50:52 <b_jonas> but yes, I can understand if you say that dropping a MutexGuard or sync::Ref has enough side effects that you want to be explicit about it
02:51:17 <ais523> for what it's worth, I am increasingly coming to view dropping a *mutable reference* as being an operation that has side effects
02:52:17 <b_jonas> if you call a method into which you pass MutexGuard by value and then that method returns then you no longer have a MutexGuard value. you could have an explicit method but it's not in the library because drop works just fine.
02:53:02 <ais523> b_jonas: right, but my point is that "it goes via drop" is a somewhat confusing implementation detail
02:53:18 <ais523> it doesn't inherently need to go via drop, it could be any method that consumes its argument
02:53:21 <b_jonas> (I mean technically such a method could sneak the MutexGuard back to you as a side effect, but obviously the one that drops the lock wouldn't do that)
02:54:02 <zzo38> What you mentioned about M;tG, it has many rules so it is different from most programming languages in many ways anyways. I think in Magic: the Gathering the "last known information" is effectively read-only anyways
02:54:07 <ais523> there's a method on CondVar, I think, that temporarily unlocks a mutex (atomically with waiting on the condition variable), and relocks it when the wait ends
02:54:29 <ais523> zzo38: I assume it would be possible for a card to change it, but think it's unlikely that such a card would be made
02:54:46 <b_jonas> I guess you could implement such an interface for a guard, even by wrapping the current MutexGuard
02:54:51 <ais523> and that method takes a MutexGuard by value and returns it again
02:55:19 <zzo38> ais523: I suppose so, if the card explicitly says it changes the last known information of an object (I do not expect that anything else could change it, although I may be wrong; many strange things can be possible that were not expected)
02:55:40 <ais523> thinking about it, I'm not even sure that would be possible to implement without overriding MutexGuard's destructor somehow
02:59:48 <ais523> but in general, having a single destructor that always runs is a mistake, in case you need to implement a method that destroys the object in a weird way
03:00:04 <b_jonas> so maybe I wasn't quite precise in how that invariant works
03:00:35 <ais523> probably the best example is in the signature of Drop – it can't take the object by value even though it logically should, because then the destructor would run itself recursively when the value goes out of scope, forever
03:00:38 <b_jonas> maybe the MutexGuard only guarantees that the mutex is locked by the current thread at times when you could borrow it
03:01:12 <ais523> (unless you deconstructed the object by pattern-matching on all its fields and moving out of them, which isn't allowed in current Rust but I've seen some very convincing arguments that it should be)
03:02:15 <ais523> I think the MutexGuard represents the fact that the mutex is currently locked – and that you can therefore lock the mutex via methods that create a MutexGuard and unlock the mutex via methods that destroy a MutexGuard – and that all of this is not inherently related to Drop at all
03:02:33 <ais523> the only purpose of the Drop implementation is to make it difficult to accidentally leak a lock, via forgetting to unlock the MutexGuard
03:02:37 <zzo38> I think it is right sometimes it is helpful and/or necessary to destroy an object in a different way than usual. Sometimes it might not be necessary to destroy an object at all. Sometimes, depending on how it is allocated, you might be able to destroy many objects at once. Or, some data remembered by it is now remembered by something else, so the object should not destroy that data.
03:03:12 <ais523> but, this may result in the mutex being unlocked too early, and the bug not being detected by the compiler because it just auto-inserts a call to `Drop::drop` which unlocks it – unlocking it should be explicit
03:03:35 <b_jonas> ais523: yes, how Drop currently works, the destructor first calls your drop method, then destroys the fields of the struct or enum variant
03:04:32 <b_jonas> ais523: hmm... I think C++ has types that can't be destroyed, but I never used them and have no idea how they actually work
03:04:33 <ais523> right, and it's implemented like that because the concept of "a destructor that runs when an object goes out of scope by any means other than mem::forget or ManuallyDrop" is kind-of broken
03:04:43 <b_jonas> because their destructor is private or something
03:05:45 <ais523> hmm… would «trait Drop { fn drop(ManuallyDrop<self>); }» work as an API, assuming a) arbitrary self types and b) the ability to move the fields out of the contents of a ManuallyDrop by pattern-matching (I'm not sure whether or not that one is currently legal)?
03:06:47 <ais523> the ManuallyDrop solves the recursive drop problem (unless you do an into_inner or the like, but that's basically equivalent to a manual recursive call)
03:08:54 <ais523> huh, ManuallyDrop has private fields
03:09:13 <ais523> it strikes me as a good candidate for a type with a public field in its public API…
03:10:09 <zzo38> I think that object-oriented programming is useful for some things but not all things, although what you expect that an object will be can also be different for different uses. In C, the FILE object is very useful (GNU allows you to define your own implementation of its interface and I think BSD also does, although this is non-standard as far as I know)
03:10:15 <b_jonas> ais523: the current language rules don't allow you to create a union whose type has a non-trivial destructor, so that wouldn't easily work
03:10:36 <b_jonas> so ManuallyDrop currently contains some language magic
03:10:40 <zzo38> Some people like to use object-oriented programming with everything even though I think that is not helpful. Some programming languages such as Java expect and require you to do so.
03:10:41 <ais523> right, I was wondering "why not just make a union with one variant" but I guess that's why
03:11:05 <b_jonas> maybe this could be solved in future versions of the language, but some language magic is fine for now
03:11:31 <ais523> I don't think Java requires you to use object-oriented programming; it requires everything to technically be a method of an object or a static method of a class, but this is trivial to work around to write entirely procedural code if you want
03:11:49 <b_jonas> it's still a valid abstraction as in it's type where if you already have ManuallyDrop then you could implement a differently named type that does exactly the same thing based on it, which is what I care about when language magic is involved
03:11:54 <zzo38> In the file https://github.com/zzo38/freeheromesh/blob/trunk/exec.c the "objtrash" function is the usual way to destroy an object (actually "destroy" is usually called first, but that is not relevant here), but "annihilate" is used as a more efficient way of destroying everything at once. I think that is one example of why you might want multiple kind of instruction
03:12:05 <ais523> it is not uncommon to use a class simply as a namespace, containing static methods that work like procedures/functions, and where there is no way to construct an object of the class
03:12:24 <b_jonas> similarly to UnsafeCell, you can't implement it in first place without language magic, but the interface is such that you can wrap it to another type generic that has the same interface
03:13:05 <b_jonas> (there may be some unresolved issues about passing those types to extern functions by value, but that's just a problem of the specs currently not being clear enough, not some fundamental limitation)
03:13:27 <zzo38> I had used Java in the past. However, what I meant is that I think all of the standard functions will require you to do object-oriented programming; if you write your own code then yes I Suppose you can do what you said. I may be wrong, since I have not done much Java programming, but it is what it seem to me
03:13:35 <ais523> b_jonas: fwiw, the blog post I linked has a safe implementation of what's effectively Cell, although there are a couple of major drawbacks that make it mostly unusable in practice
03:13:46 <b_jonas> I'm not sure if this "you could implement the same interface" idea has a name
03:14:24 <b_jonas> but usually most library types and functions try to be like that
03:14:33 <esolangs> [[Talk:Disan Count Pesudocode]] https://esolangs.org/w/index.php?diff=136864&oldid=136847 * None1 * (+364)
03:14:34 <ais523> I have often wondered whether it would be an improvement for languages to just let you implement concrete classes as though they were traits/interfaces
03:14:42 <b_jonas> not just in rust, in many other languages
03:14:55 <ais523> I think it probably isn't in Rust but might be in other languages
03:14:56 <b_jonas> there are some that do break that abstraction, like the wantarray function in perl
03:16:08 <b_jonas> what do you mean by that? "concrete classes as though they were traits/interfaces"?
03:17:02 <ais523> like, I can implement all the methods of some standard library class/struct, and then use the resulting object in places where the standard library class/struct is requested
03:17:43 <ais523> basically creating a "drop-in replacement" with the same interface
03:17:53 <ais523> this is useful sometimes, but I fear it might make the program too hard to analyse
03:18:13 <zzo38> Such thing is sometimes useful. (My own idea of operating system enforces this for security purposes, although only for objects that belong to other programs than the caller.)
03:18:36 <ais523> interestingly, Rust has some standard library functions with wantarray-style magic, but the relevant API is exposed to user code so it's possible to write working wrappers for them
03:18:54 <b_jonas> you could even unofficially call it a newtype
03:19:15 <ais523> it's the opposite of a newtype, isn't it?
03:19:29 <ais523> a newtype acts the same way as the old type, but is treated by the compiler as different
03:19:34 <b_jonas> ais523: which ones do you mean? just the ones that extract backtrace information when they panic?
03:19:46 <ais523> b_jonas: right, backtrace, caller location, etc.
03:20:13 <b_jonas> sure, and if you wrap a library type with your custom type then the compiler will treat it as different.
03:20:25 <b_jonas> you can't just pass one type to a function instead of the other
03:20:33 <ais523> oh, no – my plan was that you could
03:21:06 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
03:21:13 <ais523> a middleground would be able to say in a function signature "any type that implements all the methods of «insert standard library type here»"
03:21:31 <ais523> so that if you wanted to guarantee you got the "real" standard library type you could get it
03:21:56 -!- Lord_of_Life has joined.
03:22:00 <esolangs> [[Brainfuck/Esointerpreters]] https://esolangs.org/w/index.php?diff=136865&oldid=136303 * None1 * (+5926) /* Wenyan interpreters */
03:22:12 <ais523> I don't see how even the extreme version couldn't work, though, as long as objects (including standard library objects) are used only via their public API (including internally in the standard library)
03:23:15 <esolangs> [[Brainfuck/Esointerpreters]] M https://esolangs.org/w/index.php?diff=136866&oldid=136865 * None1 * (-5870) /* Textile interpreters */ internal link to interpreter
03:23:36 <b_jonas> ais523: so do you mean like every time you define a struct, you implicitly define something like a trait that contains all the interface of that type, and then you can make a function that accepts a dyn of that trait, which needs a vtable passed because the ABIs can be different?
03:23:41 <ais523> and think it would generally be a good thing for standard library objects to generally not assume things about each others' internals
03:24:03 <ais523> b_jonas: yes – the original plan was intended for languages where all objects are passed as dyns anyway
03:24:25 <ais523> which is what made me suspect it would probably be inappropriate for Rust
03:24:45 <ais523> where dyns are weird and unusual
03:24:53 <b_jonas> yeah, you can do something like that in a language like python where an object always contains a pointer to its class, though not quite everything you want
03:24:57 <ais523> (and less efficient than the normal calling convention)
03:25:17 <ais523> it is strange for an object-oriented language to *not* store a vtable in every object
03:25:18 <b_jonas> it doesn't always work, but you can often pass the wrong type of object if you add enough magic around your custom reimplementation type
03:25:39 <zzo38> Sometimes such a thing is inefficient though. But, sometimes it is helpful
03:25:51 <ais523> the only ones I can think of offhand are C++ and Rust
03:26:00 <ais523> and even C++ tends to vtable quite a lot
03:26:04 <b_jonas> the problem isn't really that they're weird and unusual but that they have a significant runtime cost that you will often not be able to optimize away, especially for calls across compilation units
03:26:25 <ais523> right; and most languages pay that cost on everything they do
03:26:56 <b_jonas> (technically it needn't be an actual pointer to the class, but the information about the type has to be there at runtime)
03:27:05 <ais523> this may help to explain why Java is normally JIT-compiled and LLVM has lots of optimizations to try to devirtualise C++
03:27:26 <ais523> doesn't Perl use a string containing the name of the class?
03:27:38 <esolangs> [[Brainfuck/Esointerpreters]] https://esolangs.org/w/index.php?diff=136867&oldid=136866 * None1 * (+59) /* Textile interpreters */
03:27:55 <esolangs> [[Brainfuck/Esointerpreters]] M https://esolangs.org/w/index.php?diff=136868&oldid=136867 * None1 * (-2) /* Piet interpreters */
03:27:59 <b_jonas> I dunno. do you mean traditional perl or this modern OOP thing that they're trying to add now
03:28:02 <esolangs> [[User:PkmnQ/Alt Flow]] N https://esolangs.org/w/index.php?oldid=136869 * PkmnQ * (+1593) Created page with "[[Alt Flow]] is a family of esolangs that consists entirely of control flow commands. == Commands == * SKIP n - SKIP the next n commands. (Undefined behavior if there are less than n commands after this one.) * COPY n - COPY the next n commands and append th
03:28:03 <zzo38> It is what I thought, that especially for calls across compilaion units, it cannot easily be optimized. So, I generally will not use it except the FILE object anyways
03:28:25 <b_jonas> I know basically nothing about perl's new features, I mostly abandonned following the developments
03:28:35 <ais523> b_jonas: the way Perl did it during the bulk of Perl 5's existence
03:28:48 <b_jonas> I just use python3 for basically everything that I used to use perl for
03:29:17 <zzo38> Another issue with such a thing is that sometimes you will want to access the underlying object, and the programming language or the API in use might not have a way to do that. I had once said that I had wanted a "fgetcookie" function in GNU, since sometimes it is useful for this purpose.
03:29:22 <ais523> I just use Perl in a relatively traditional way, and generally don't use OO in it except when I need to interact with a library written that way
03:30:45 <zzo38> Do you think "fgetcookie" is good?
03:30:58 <b_jonas> that varies a lot in my python programs. sometimes I store everything in plain objects of library types like arrays, sometimes I define simple classes for even trivial things, depends on how much I feel like trying to document the code
03:31:04 <ais523> when I write Rust, though, I use its OO-equivalent fairly heavily; I think that's because I like the compile-time guarantees, having more specific types gives you better guarantees, and if you're going to the trouble of making types anyway it can make sense to give them methods
03:31:12 <b_jonas> wrapping in custom types helps a lot to make the code self-documenting
03:31:29 <ais523> zzo38: what does it return on a non-custom FILE * that was created from a file on disk using the standard APIs?
03:31:36 <b_jonas> because the class limits the interface of how I want to use the value
03:31:46 <esolangs> [[Wenyan]] https://esolangs.org/w/index.php?diff=136870&oldid=134521 * None1 * (-8652) Add headings
03:32:50 <ais523> my C is fairly object-oriented nowadays, e.g. I like to have accessor macros for C structs so tht I can change the internals (and in particular so that I can give them side effects)
03:33:20 <zzo38> ais523: It would return an unspecified value (possibly null); you should not call fgetcookie in such a case (or pass the FILE* object to a function that does so), just as much as you should not call pclose on a FILE* object that was not obtained by popen.
03:33:39 <ais523> I accidentally introduced a bug into 3.7 because I changed the quantity of an item without changing the weight to match – a good set of accessors would have made that mistake impossible
03:34:13 <b_jonas> ais523: why are they macros rather than inline functions?
03:34:45 <ais523> zzo38: hmm, in that case the code knows that it's a cookie-file anyway, so you might as well create a structure that contains both the file and a cookie reference, mightn't it?
03:34:57 <ais523> sorry, I thought that but forgot to put it into the sentence as I was writing it
03:35:12 <b_jonas> yeah, it's kind of hard with nethack because the source has so much old style code remaining
03:35:28 <b_jonas> one day someone will need to rewrite the whole thing
03:35:41 <ais523> I do use inline functions for that sort of thing sometimes, but am still not really sure how much C99 support I want to assume in my C code
03:36:20 <ais523> and inline semantics are confusing in C – macros are easier to understand, and pretty much equivalent if you remember the extra parentheses and backslashes
03:36:31 <zzo38> ais523: A reason why you might not is in case you want to pass it directly to fprintf, etc instead of having to keep track of the object separately (especially if the structure is not intended to be exposed).
03:36:57 <b_jonas> wait what? you don't want to assume even that part of C99? I can understand not assuming the runtime array length part, but C99 inline functions aren't that big of a magic
03:37:17 <ais523> b_jonas: they're implemented differently in gcc with default settings from the way they're implemented in the standard
03:37:37 <zzo38> I had mostly used gnu89 in my own C programs, although more recently I have used gnu99 because the ability to declare a variable in the heading of a for loop is sometimes useful in macros.
03:37:43 <ais523> need an implicit --std=c99 or the like to get the standard behaviour
03:37:51 <ais523> and *both* behaviours are confusing
03:37:52 <b_jonas> ais523: isn't that mostly about whether inline implies static for a function declaration?
03:38:13 <zzo38> I don't use "inline" without "static" anyways
03:38:17 <b_jonas> that's a genuine difference between C versions, but you can abstract around it with (yes, I know) a macro like ECB_INLINE
03:38:18 <ais523> it's about the way you write the out-of-line definition, which I guess is the same thing
03:38:46 <b_jonas> which expands to either `inline` or `static inline`
03:38:52 <ais523> I guess macros have the advantage that you know the out-of-line definition isn't needed
03:39:23 <b_jonas> also doesn't gcc default to that these days? maybe that's only for C++
03:39:39 <ais523> I thought the main confusion was related to "extern inline" which means two different things depending on version and I can't remember either of them
03:40:10 <b_jonas> nope, I'm wrong, that macro is called ecb_inline, and it expands to either `static inline` or `static`
03:40:32 <b_jonas> `static` is for old compilers that don't have C99 inline functions, `static inline` for C99 and C++
03:40:35 <HackEso> static`? No such file or directory
03:41:24 <ais523> the problem with `static inline` is that it can generate a lot of duplicate out-of-line copies
03:41:58 <ais523> no, macros can't have out-of-line copies
03:42:15 <b_jonas> sure, but it's still the same effect with lots of inline copies
03:42:26 <ais523> the inline copies are supposed to be duplicates
03:42:44 <ais523> normally you'd do this in situations where an inline copiy is cheaper than a function call anyway
03:43:14 <ais523> but that argument doesn't apply to the out-of-line copies because they still have to pay the function call overhead
03:44:30 <ais523> so generally, you want the inline definition to appear in a header file that's included by everything that accesses the object, and the out-of-line definition to appear only once in the whole program, so that all the out-of-line calls go to the same place
03:45:28 <ais523> anyway, I should go to bed
03:45:37 -!- ais523 has quit (Quit: quit).
03:45:42 <b_jonas> yes, the C++ rules are probably better for this, C++ requires that if you have two classes with the same namespaced name across compilation units or two inline functions with the same namespaced name and prototype across compilation units then they are the same so dupes can be eliminated at link time
04:03:42 -!- bookworms has quit (Remote host closed the connection).
04:03:58 -!- bookworms has joined.
04:31:44 <zzo38> I had some ideas about abilities, hold item, moves, etc in Pokemon, such as: a move that is guaranteed to be executed if it has been successfully selected; it cannot be stopped by sleeping, paralysis, fainting, etc, although protecting from the move is still possible and it can still be prevented if the battle ends before it gets a chance to be executed.
04:52:17 <esolangs> [[User talk:PkmnQ/Alt Flow]] N https://esolangs.org/w/index.php?oldid=136871 * Gggfr * (+137) Created page with "5 and 3 are the same cuz non-negative int = positive int. -~~~~"
04:59:23 <esolangs> [[Ultimate Golfing Simulator 3000]] M https://esolangs.org/w/index.php?diff=136872&oldid=127474 * Rdococ * (+39) /* Computational Class */
04:59:40 <esolangs> [[3ME]] https://esolangs.org/w/index.php?diff=136873&oldid=136686 * Gggfr * (+5) the user part still must be visible. and what do you mean by not notable
05:10:02 <esolangs> [[3ME]] https://esolangs.org/w/index.php?diff=136874&oldid=136873 * Unname4798 * (-5) I WOULDN'T REVEAL THE REAL NAME
05:12:11 <esolangs> [[User talk:PkmnQ/Alt Flow]] https://esolangs.org/w/index.php?diff=136875&oldid=136871 * PkmnQ * (+338) difference between 5, 4, and 3
05:30:06 -!- Sgeo has quit (Read error: Connection reset by peer).
05:54:47 -!- bookworms has quit (Quit: I give the F*%k up! Have a nice day!).
06:21:46 -!- Deepfriedice has joined.
06:39:00 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=136876&oldid=136784 * BCByte * (+25) /* Introductions */
06:53:09 <esolangs> [[Turmin]] https://esolangs.org/w/index.php?diff=136877&oldid=136833 * Ttulka * (+976) /* Computational class */ add CTS simulation
06:56:31 <esolangs> [[Turmin]] M https://esolangs.org/w/index.php?diff=136878&oldid=136877 * Ttulka * (+0) /* Computational class */ links
07:16:17 <esolangs> [[BrainfXX]] N https://esolangs.org/w/index.php?oldid=136879 * None1 * (+3024) Created page with "'''BrainfXX''' is an esolang, or a family of 256 esolangs, invented by [[User:None1]]. ==Commands== The name of each language is <code>Brainf00</code> to <code>BrainfFF</code>, the last 2 characters are hex digits. When converted to binary, each digit means whether the c
07:16:57 <esolangs> [[BrainfXX]] M https://esolangs.org/w/index.php?diff=136880&oldid=136879 * None1 * (-1164) /* Interpreter in Python */
07:18:24 <esolangs> [[BrainfXX]] M https://esolangs.org/w/index.php?diff=136881&oldid=136880 * None1 * (+195)
07:19:08 -!- Deepfriedice has quit (Ping timeout: 248 seconds).
07:20:00 <esolangs> [[BrainfXX]] M https://esolangs.org/w/index.php?diff=136882&oldid=136881 * None1 * (+0) /* Interpreter in Python */
07:20:42 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=136883&oldid=136262 * None1 * (+15) /* B */
07:21:18 <esolangs> [[User:None1]] M https://esolangs.org/w/index.php?diff=136884&oldid=136313 * None1 * (+57)
07:21:49 <esolangs> [[BrainfXX]] M https://esolangs.org/w/index.php?diff=136885&oldid=136882 * None1 * (+9)
07:22:16 <esolangs> [[BrainfXX]] M https://esolangs.org/w/index.php?diff=136886&oldid=136885 * None1 * (+24) /* Equivalents to other languages */
07:39:28 <esolangs> [[User talk:/w/wiki/index.php/Talk:index.php/Main page]] https://esolangs.org/w/index.php?diff=136887&oldid=134935 * Unicodes * (+163)
07:42:26 <esolangs> [[User talk:/w/wiki/index.php/Talk:index.php/Main page]] https://esolangs.org/w/index.php?diff=136888&oldid=136887 * Unicodes * (+80)
07:56:12 -!- tromp has joined.
08:00:33 <esolangs> [[3ME]] M https://esolangs.org/w/index.php?diff=136889&oldid=136874 * None1 * (+5) Undo revision [[Special:Diff/136874|136874]] by [[Special:Contributions/Unname4798|Unname4798]] ([[User talk:Unname4798|talk]]) Gggfr was right, userspace links should have User: visible
08:00:55 -!- Deepfriedice has joined.
08:03:13 <esolangs> [[Mihaieso esomixup]] M https://esolangs.org/w/index.php?diff=136890&oldid=136859 * None1 * (+23)
08:06:07 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:07:27 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:Ractangle/AREA]] to [[User:Ractangle/JS-CODE]]
08:08:59 <esolangs> [[User talk:/w/wiki/index.php/Talk:index.php/Main page]] https://esolangs.org/w/index.php?diff=136893&oldid=136888 * None1 * (+466)
08:15:05 <esolangs> [[User:Ractangle/JS-CODE]] https://esolangs.org/w/index.php?diff=136894&oldid=136891 * Ractangle * (+350)
08:15:19 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:Ractangle/JS-CODE]] to [[JS-CODE]]
08:21:44 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=136897&oldid=136895 * Ractangle * (+196)
08:22:14 <esolangs> [[Translated JS]] M https://esolangs.org/w/index.php?diff=136898&oldid=133147 * None1 * (+2)
08:22:42 <esolangs> [[Translated JS]] M https://esolangs.org/w/index.php?diff=136899&oldid=136898 * None1 * (+49)
08:22:53 <esolangs> [[JS-CODE]] https://esolangs.org/w/index.php?diff=136900&oldid=136897 * Ractangle * (-3)
08:39:14 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[JS-CODE]] to [[Waretel BASIC]]
08:39:36 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136903&oldid=136901 * Ractangle * (+6)
08:40:59 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136904&oldid=136903 * Ractangle * (+11)
08:43:49 <esolangs> [[Talk:Disan Count Pesudocode]] https://esolangs.org/w/index.php?diff=136905&oldid=136864 * Ractangle * (+1) None1 you forgot an another colon
08:44:53 <esolangs> [[Disan Count Pesudocode]] https://esolangs.org/w/index.php?diff=136906&oldid=136812 * Ractangle * (+39) /* Disan Count */
08:46:29 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136907&oldid=136904 * Ractangle * (-106)
08:48:04 <esolangs> [[Translated JS/None1]] N https://esolangs.org/w/index.php?oldid=136908 * None1 * (+2395) Created page with "Let's make [[Translated JS]] even worse! Take the semiproduct: <pre> Function evaluate () {int e=.Y `\n`;let o="",ln=y=p=C=p=C= + o,,V; ({p e) _con_ if ((! a + b)||p==[])continue;if(AV==0&&n=="==start testing " + a + y + "=="&& + St&&! (V={},P=C=p=a+! V))cont
09:03:13 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136909&oldid=136907 * Ractangle * (+176)
09:04:18 <esolangs> [[3ME]] https://esolangs.org/w/index.php?diff=136910&oldid=136889 * Unname4798 * (-169) DON'T LINK MY USER PAGE AT ALL.
09:14:40 -!- tromp has joined.
09:23:36 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136911&oldid=136909 * Ractangle * (+60)
09:32:46 -!- craigo has quit (Quit: Leaving).
10:01:09 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136912&oldid=136911 * Ractangle * (-9)
10:03:31 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136913&oldid=136912 * Ractangle * (+4) /* Hello, world! */
10:04:54 <esolangs> [[Hello world program in esoteric languages (T-Z)]] https://esolangs.org/w/index.php?diff=136914&oldid=136264 * Ractangle * (+49) /* VTL */
10:07:27 -!- __monty__ has joined.
10:14:54 -!- wib_jonas has joined.
10:50:02 -!- X-Scale has joined.
10:55:41 -!- X-Scale has quit (Ping timeout: 256 seconds).
11:32:25 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:02:41 -!- mtm has quit (Ping timeout: 244 seconds).
12:06:08 -!- mtm has joined.
12:13:59 -!- amby has joined.
12:29:20 -!- wib_jonas has quit (Quit: Client closed).
12:35:20 <esolangs> [[Talk:Diexponae]] N https://esolangs.org/w/index.php?oldid=136915 * Yayimhere * (+211) Created page with "this is... not a new computational class. just cuz it uses the quadratic formula doesn't mean its a new computational class ~~~~"
12:38:30 -!- wib_jonas has joined.
12:52:04 -!- bookworms has joined.
12:53:22 -!- bookworms has quit (Max SendQ exceeded).
12:54:43 -!- bookworms has joined.
13:02:28 -!- wib_jonas91 has joined.
13:03:18 -!- wib_jonas has quit (Killed (NickServ (GHOST command used by wib_jonas91))).
13:03:22 -!- wib_jonas91 has changed nick to wib_jonas.
13:08:17 -!- wib_jonas has quit (Ping timeout: 256 seconds).
13:11:43 -!- tromp has joined.
13:13:31 -!- wib_jonas has joined.
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry]] to [[User:]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/About Sandbox War]] to [[User:/About Sandbox War]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/About more Categories]] to [[User:/About more Categories]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/Discussion]] to [[User:/Discussion]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/Sandbox]] to [[User:/Sandbox]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/Sandbox/TEST]] to [[User:/Sandbox/TEST]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/Sandbox/TEST2]] to [[User:/Sandbox/TEST2]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/Sandbox/There are some User are most contributions in this wiki.]] to [[User:/Sandbox/There are some User are most contributions in this wiki.]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User:PrySigneToFry/w/talk/user/talk/language/language/sandbox/sandbox]] to [[User:/w/talk/user/talk/language/language/sandbox/sandbox]]
13:16:08 <esolangs> [[Special:Log/move]] move * Ractangle * moved [[User talk:PrySigneToFry]] to [[User talk:]]
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:]] to [[User:PrySigneToFry]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/About Sandbox War]] to [[User:PrySigneToFry/About Sandbox War]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/About more Categories]] to [[User:PrySigneToFry/About more Categories]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/Discussion]] to [[User:PrySigneToFry/Discussion]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/Sandbox]] to [[User:PrySigneToFry/Sandbox]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/Sandbox/TEST]] to [[User:PrySigneToFry/Sandbox/TEST]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/Sandbox/TEST2]] to [[User:PrySigneToFry/Sandbox/TEST2]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/Sandbox/There are some User are most contributions in this wiki.]] to [[User:PrySigneToFry/Sandbox/There are some User are most contributions in this wiki.]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User:/w/talk/user/talk/language/language/sandbox/sandbox]] to [[User:PrySigneToFry/w/talk/user/talk/language/language/sandbox/sandbox]] over redirect
13:16:27 <esolangs> [[Special:Log/move]] move_redir * Ractangle * moved [[User talk:]] to [[User talk:PrySigneToFry]] over redirect
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry]] by overwriting: Deleted to make way for move from "[[User:]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/About Sandbox War]] by overwriting: Deleted to make way for move from "[[User:/About Sandbox War]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/About more Categories]] by overwriting: Deleted to make way for move from "[[User:/About more Categories]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/Discussion]] by overwriting: Deleted to make way for move from "[[User:/Discussion]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/Sandbox]] by overwriting: Deleted to make way for move from "[[User:/Sandbox]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/Sandbox/TEST]] by overwriting: Deleted to make way for move from "[[User:/Sandbox/TEST]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/Sandbox/TEST2]] by overwriting: Deleted to make way for move from "[[User:/Sandbox/TEST2]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/Sandbox/There are some User are most contributions in this wiki.]] by overwriting: Deleted to make way for move from "[[User:/Sandbox/There are some User are most contributions in this wiki.]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User:PrySigneToFry/w/talk/user/talk/language/language/sandbox/sandbox]] by overwriting: Deleted to make way for move from "[[User:/w/talk/user/talk/language/language/sandbox/sandbox]]"
13:16:27 <esolangs> [[Special:Log/delete]] delete_redir * Ractangle * Ractangle deleted redirect [[User talk:PrySigneToFry]] by overwriting: Deleted to make way for move from "[[User talk:]]"
13:28:11 <esolangs> [[Waretel BASIC]] https://esolangs.org/w/index.php?diff=136956&oldid=136913 * Ractangle * (+86)
13:37:19 -!- wib_jonas has quit (Quit: Client closed).
13:40:03 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
13:50:43 <esolangs> [[Preface]] N https://esolangs.org/w/index.php?oldid=136957 * Yayimhere * (+1060) Created page with "'''Preface''' is a esolang by [[User:Yayimhere]] because of a discord discussion about [[No-code esolang|No-code esolangs]]. == semantics == ignore program and take user input. the input will be the memory. the input is bounded to 256 chars but memory is unbounded. t
13:59:09 <esolangs> [[Preface]] https://esolangs.org/w/index.php?diff=136958&oldid=136957 * Yayimhere * (+1)
14:23:49 <esolangs> [[Talk:Rozpach]] N https://esolangs.org/w/index.php?oldid=136959 * Yayimhere * (+120) Created page with "is there a proof of it being TC? ~~~~"
14:36:13 <HackEso> nitia is the inventor of all things. The BBC invented her.
14:57:32 <esolangs> [[User:Yayimhere]] https://esolangs.org/w/index.php?diff=136960&oldid=136771 * Yayimhere * (+14)
14:59:00 <esolangs> [[Preface]] https://esolangs.org/w/index.php?diff=136961&oldid=136958 * Yayimhere * (+93)
14:59:06 -!- tromp has joined.
15:01:57 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=136962&oldid=135229 * Yayimhere * (+227) /* category:joke proofs */
15:10:27 <esolangs> [[Nope]] https://esolangs.org/w/index.php?diff=136963&oldid=136692 * Yayimhere * (+35)
15:26:31 -!- sprout has quit (Remote host closed the connection).
15:32:08 -!- sprout has joined.
15:37:18 <int-e> Well this island was a pain to get to (a monster's expedition; I don't think it's a spoiler since I've reset all the islands to a natural solved state) https://int-e.eu/~bf3/tmp/ame-tough-island.jpg
15:37:59 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User talk:]]": redirect left behind after reverted move
15:38:08 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/w/talk/user/talk/language/language/sandbox/sandbox]]": redirect left behind after reverted move
15:38:17 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/Sandbox/There are some User are most contributions in this wiki.]]": redirect left behind after reverted move
15:38:27 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/Sandbox/TEST2]]": redirect left behind after reverted move
15:38:35 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/Sandbox/TEST]]": redirect left behind after reverted move
15:38:42 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/Sandbox]]": redirect left behind after reverted move
15:38:49 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/Discussion]]": redirect left behind after reverted move
15:38:57 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/About more Categories]]": redirect left behind after reverted move
15:39:04 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:/About Sandbox War]]": redirect left behind after reverted move
15:39:11 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[User:]]": redirect left behind after reverted move
16:27:56 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:39:39 -!- Deepfriedice has quit (Ping timeout: 240 seconds).
16:44:50 <esolangs> [[Collab]] https://esolangs.org/w/index.php?diff=136964&oldid=136863 * Qawtykit * (+558) added
17:13:36 <esolangs> [[Talk:Diexponae]] https://esolangs.org/w/index.php?diff=136965&oldid=136915 * BoundedBeans * (+451)
17:23:08 <esolangs> [[Hyperheptefunge-98]] https://esolangs.org/w/index.php?diff=136966&oldid=136828 * BoundedBeans * (-1) "thing"->"this"
17:25:40 -!- Deepfriedice has joined.
17:29:28 <esolangs> [[Hyperheptefunge-98]] https://esolangs.org/w/index.php?diff=136967&oldid=136966 * BoundedBeans * (+202) Make literal space followed by comments unambiguous
17:32:25 <esolangs> [[Preface]] M https://esolangs.org/w/index.php?diff=136968&oldid=136961 * PythonshellDebugwindow * (+23) Category
17:35:05 <esolangs> [[Mihaieso esomixup]] M https://esolangs.org/w/index.php?diff=136969&oldid=136890 * PythonshellDebugwindow * (+66) Categories
17:35:51 <esolangs> [[Disan Count Pesudocode]] M https://esolangs.org/w/index.php?diff=136970&oldid=136906 * PythonshellDebugwindow * (+50) Categories
17:42:04 <esolangs> [[Special:Log/upload]] upload * ArsenicCatnip * uploaded "[[File:Larry.png]]"
17:43:41 <esolangs> [[Larry]] https://esolangs.org/w/index.php?diff=136972&oldid=136668 * ArsenicCatnip * (+25) Added picture of larry claaaaaaw
17:55:06 <esolangs> [[Larry]] https://esolangs.org/w/index.php?diff=136973&oldid=136972 * ArsenicCatnip * (+120) Added a link to a page about Larry Tesler
18:44:51 -!- tromp has joined.
18:56:20 -!- bookworms has quit (Quit: I give the F*%k up! Have a nice day!).
20:13:56 -!- X-Scale has joined.
20:14:25 -!- craigo has joined.
20:19:31 -!- X-Scale has quit (Ping timeout: 256 seconds).
20:30:38 <esolangs> [[Mihaieso esomixup]] https://esolangs.org/w/index.php?diff=136974&oldid=136969 * Tommyaweosme * (-9) *coughs twice* forget the ____fuck?
20:30:58 <esolangs> [[Mihaieso esomixup]] M https://esolangs.org/w/index.php?diff=136975&oldid=136974 * Tommyaweosme * (+0) typo
20:37:35 <esolangs> [[Command per command]] N https://esolangs.org/w/index.php?oldid=136976 * Tommyaweosme * (+654) Created page with "{{lowercase}}command per command is an esolang designed to have the biggest possible self interpeter. == how it works == every program asks for input, and then every command after that is a marker for if that command is in the interpreter or not. the co
20:44:20 <esolangs> [[User talk:Page crapper from explain xkcd]] N https://esolangs.org/w/index.php?oldid=136977 * Tommyaweosme * (+208) Created page with "omg are they gonna make a third one soon???? ~~~~"
20:54:25 -!- fowl has quit (Ping timeout: 260 seconds).
20:55:58 <esolangs> [[Blast protection]] N https://esolangs.org/w/index.php?oldid=136978 * Tommyaweosme * (+993) Created page with "{{lowercase}}blast protection is an esolang based on obsidian and tnt. == blocks == o obsidian r red tnt b blue tnt w wooden planks c cobblestone d dirt g glass # bedrock % glitch block the tnt blows up to the right always == how the blocks interac
20:57:28 <esolangs> [[User:Tommyaweosme]] https://esolangs.org/w/index.php?diff=136979&oldid=136405 * Tommyaweosme * (-1812) Replaced content with "== minecraft enchantment saga == * [[dolfins grace]] * [[blast protection]] * [[fire resistance]]"
20:57:51 <esolangs> [[Fire resistance]] N https://esolangs.org/w/index.php?oldid=136980 * Tommyaweosme * (+84) Created page with "this esolang is scheduled to release to the public on august 29th! see you then! :D"
20:58:04 <esolangs> [[Fire resistance]] https://esolangs.org/w/index.php?diff=136981&oldid=136980 * Tommyaweosme * (+14)
21:02:55 <esolangs> [[User talk:MihaiEso]] https://esolangs.org/w/index.php?diff=136982&oldid=136858 * Tommyaweosme * (+187) /* Mihai is unbanned! */
21:06:45 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:09:25 <esolangs> [[User:Tommyaweosme/simpler playlist]] N https://esolangs.org/w/index.php?oldid=136983 * Tommyaweosme * (+339) Created page with "simpler playlist (.smpl) is [[user:mihaieso]]'s simple playlist but simpler == all it is == all it is is just a list of song files. thats it. none of that comment shit or this metadata crap. just songs. == example == When-I-Met-You-in-The
21:09:35 <esolangs> [[User:Tommyaweosme/simpler playlist]] https://esolangs.org/w/index.php?diff=136984&oldid=136983 * Tommyaweosme * (+14)
21:21:53 <esolangs> [[Fire resistance]] M https://esolangs.org/w/index.php?diff=136985&oldid=136981 * PythonshellDebugwindow * (+33) Stub, category
22:02:30 <b_jonas> ais523: in "http://ais523.me.uk/blog/scoped-generics.html" I think "improvved" is a typo and you wanted to write "improved" instead
22:03:19 -!- ais523 has joined.
22:03:28 -!- Deepfriedice has quit (Remote host closed the connection).
22:03:50 <ais523> b_jonas: I suspect that too; "improvved" is actually a real word but I don't remember intending to use it while writing that blog post
22:05:02 <ais523> fortunately, I recently updated my blog software to the extent that I could actually fix posts after posting them
22:05:05 <ais523> so, the typo should be gone now
22:05:28 <b_jonas> ais523: my question is, would this allow you write something like { let const b: (i32, i32) = (4, 5); let x: SparseBigInt<b.0> = Default::default(); let y: SparseBigInt<b.1> = Default::default(); } ?
22:05:55 <ais523> not the way that I've currently designed it, although that seems like a reasonable extension
22:11:43 <b_jonas> These scoped generics sounds like an interesting idea. I'm not entirely convinced that the mut reference part works, but it's probably worth to try to find out if it works and why not if it doesn't.
22:15:49 <b_jonas> The other obvious question is that you don't mention in this blog entry is, how do languages like Haskell solve the kind of problem for which you need the full scoped generics in rust?
22:25:08 <ais523> I don't know enough Haskell to answer that, but it's an interesting question
22:25:47 <b_jonas> this kind of problem comes up in other languages too where the type system is complicated enough that you want to prove consistency stuff like this
22:26:03 <b_jonas> and haskell does have ST that uses the unique lifetime magic part somehow
22:26:53 <b_jonas> and it has these question mark variable thingies too that might be relevant, but I also don't really know how they work
22:28:12 <ais523> I would be astonished if I'd somehow managed to come up with a type theory idea that didn't already exist as a Haskell extension :-D
22:36:49 <b_jonas> I'd also like to know about this extra magic where you can impl a trait on a type that depends on an extra scoped generic. I wonder if it has extra restrictions on when you can or cannot impl a trait this way.
22:38:17 <b_jonas> and what restrictions there are on using such a trait.
22:40:34 -!- zzo38 has quit (Ping timeout: 260 seconds).
22:46:11 <ais523> logically there shouldn't be
22:46:37 <ais523> unless I'm missing something
22:49:22 -!- Sgeo has joined.
22:54:02 <b_jonas> my problem here is that the example that you give is that if you impl Drop for a type with a scoped generic parameter then whenever your code wants to call the destructor of this object it'll know that it's still in the lifetime of that generic parameter and has access to the value associated with that scoped generic argument. even if that does work, this is a very bad example because Drop is a really
22:54:08 <b_jonas> restricted special trait: you won't find an unrelated crate that defines a generic fn foo<T: Drop>(x: &mut T) where you have to figure out how to compile a call to this function, because Drop is never used as a generic bound like that. you'll need to show examples where the function may be used as a trait bound, and the argument might not be covariant on the lifetime of the scoped generic, etc.
23:03:58 * sprout remembers chat that Haskell can sidestep many issues in type theory by having invariant types on non-mutable data
23:04:13 <b_jonas> If you take that example where your scoped generic value is a &mut Vec that lives for only as long as the scope, and you define a struct generic over this that stores an index into that vec, then can you just implement a Deref on it that borrows an element of the vector, and similarly DerefMut, and then just call a generic function from another create that takes such an index and borrows or mut borrows
23:04:19 <b_jonas> it, or takes a mut ref to such an index and tries to allocate a new one (through a separate allocation trait)
23:05:37 <ais523> you can but there is a rule that you can't use other generics while borrowing a mutable-reference scoped generic
23:06:04 <ais523> so at any time you are actively accessing the mutable reference, you have no way to access a second copy of it
23:06:18 <ais523> ("other generics" here includes type generics in addition to scoped generics)
23:06:18 <b_jonas> and when you compile that, will the vtable pointer point to a vtable on the stack that contains the vector in a fixed position such that the methods can access that vector?
23:07:05 <ais523> I said in my article that I don't know whether or not this works with trait objects
23:07:14 <ais523> and I don't think anything else has a vtable?
23:08:21 <b_jonas> if another create has a generic fn foo<T: Deref>(...), then when you compile a call to this from yoru crate, you have to pass a hidden argument that represents impl Deref for T, so that foo can call methods from that one. that hidden argument is what I call a vtable.
23:08:29 <b_jonas> there's no dyn Trait objects involved here
23:09:05 <b_jonas> normally the hidden argument that you pass is a constant, there's only one for each concrete type if you discount lifetime parameters in it
23:09:17 <ais523> b_jonas: I thought it just got monomorphised at compile time
23:11:32 <b_jonas> yeah, I guess it needs to do that
23:12:22 <b_jonas> so then the resulting function would take a mut reference to that vector as an extra argument in this case
23:37:45 -!- bookworms has joined.
23:43:27 -!- __monty__ has quit (Quit: leaving).