00:16:30 <esolangs> [[Quite BASIC]] https://esolangs.org/w/index.php?diff=158304&oldid=158205 * Tommyaweosme * (+9311)
00:20:59 <esolangs> [[Markov algorithm]] https://esolangs.org/w/index.php?diff=158305&oldid=156494 * Tommyaweosme * (+437) added explanation of mass
00:33:50 -!- amby has quit (Remote host closed the connection).
00:46:08 <esolangs> [[Negative Acknowledgement]] N https://esolangs.org/w/index.php?oldid=158306 * Tommyaweosme * (+1477) Created page with "{{wrongtitle|title=}} is a language designed to be uninterpretable. If any interpreter is found, it will change its own Esolangs.org page within a ~231 years, unless a specific computer in an underground bunker in the Pacific ocean running Windows
00:54:43 -!- chloetax has quit (Remote host closed the connection).
02:50:33 <esolangs> [[Talk:Negative Acknowledgement]] N https://esolangs.org/w/index.php?oldid=158307 * Aadenboy * (+306) Created page with "what about compilation? ~~~~"
04:41:27 <esolangs> [[Talk:Negative Acknowledgement]] https://esolangs.org/w/index.php?diff=158308&oldid=158307 * Cycwin * (+48)
04:56:32 -!- Lord_of_Life has quit (Ping timeout: 265 seconds).
04:56:59 -!- Lord_of_Life has joined.
05:10:00 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Cannot easily used]]": unapproved/undiscussed category; this can probably be handled by see-alsos for the time being, and even if it turns out to be a good idea, the name is wrong
05:10:00 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category talk:Cannot easily used]]": Deleted together with the associated page with reason: unapproved/undiscussed category; this can probably be handled by see-alsos for the time being, and even if it turns out to be a good idea, the name is wrong
05:11:39 <esolangs> [[Talk:Boltzmann brainfuck]] N https://esolangs.org/w/index.php?oldid=158309 * Ais523 * (+225) a duplicate?
05:19:08 -!- chloetax has joined.
05:19:32 -!- chloetax has quit (Remote host closed the connection).
05:19:57 -!- chloetax has joined.
05:41:22 <zzo38> Does any browser display a visual representation of the hash of the server certificate?
05:44:32 <zzo38> I had mentioned before, the cardinal arithmetic of categories, and I think someone mentioned ordinal arithmetic. Can ordinal arithmetic of categories be defined? I don't know.
06:08:50 -!- Sgeo has quit (Read error: Connection reset by peer).
06:16:20 -!- tromp has joined.
08:04:33 <b_jonas> zzo38: ooh, with some optimized deterministic from seed image generators, with the user's choice between different styles such as anime girls, luxury cars, natural landscape Iceland, natural landscape South America, etc
08:09:11 <esolangs> [[Rinuk]] https://esolangs.org/w/index.php?diff=158310&oldid=156918 * JIT * (+24)
11:14:24 <esolangs> [[User talk:Aadenboy/Self-equaling squares]] https://esolangs.org/w/index.php?diff=158311&oldid=157532 * PkmnQ * (+1528) Half a proof
11:20:40 <esolangs> [[Special:Log/newusers]] create * Elphan * New user account
11:28:38 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=158312&oldid=158206 * Elphan * (+129) /* Introductions */
11:33:51 <esolangs> [[Ampell]] N https://esolangs.org/w/index.php?oldid=158313 * Elphan * (+2370) Created page with "== Description == Ampell is a small programming language that uses a stack to do calculations and run commands. It tries to keep things simple by using only a few symbols for different actions. You can push values on a stack, do math, check conditions, and use variables
11:35:24 <esolangs> [[BrainWrite]] M https://esolangs.org/w/index.php?diff=158314&oldid=156873 * JIT * (+2) /* Input Program */
11:37:32 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158315&oldid=158313 * Elphan * (-370) /* Syntax */
11:37:39 -!- amby has joined.
11:41:49 <esolangs> [[Special:Log/newusers]] create * Upcarry1 * New user account
11:45:56 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158316&oldid=158315 * Elphan * (-237)
12:22:17 -!- ais523 has joined.
12:22:59 <ais523> a problem that came up in some code that I was writing and I'm still thinking about it: is there a list implementation that supports efficient clone, uncons and append (i.e. concatenation of two lists)?
12:23:10 <ais523> I can easily do two out of three, but all three at once is proving difficult
12:23:39 <ais523> ("efficient clone" is most obviously implemented by making the lists immutable and refcounted, but that makes the other two properties hard to satisfy)
12:23:52 -!- wib_jonas has joined.
12:24:08 <ais523> I don't need any other operations other than writing list literals and iterating over the lists (which can be done by cloning them and then calling uncons repeatedly)
12:25:12 <wib_jonas> ais523: don't some of the balanced trees do that? red-black trees or AVL trees if you want log time, or finger trees if you want amortized constant time
12:25:43 <wib_jonas> s/red-black trees or AVL trees/red-black trees or 2-3 trees or AVL trees/
12:25:50 <ais523> including clone? I haven't heard of finger trees, I'll check then
12:26:08 <wib_jonas> you were trying to write a library for the 2-3 trees, weren't you?
12:26:14 <ais523> finger trees look really promising, actually
12:26:19 <ais523> wib_jonas: yes, a long time ago
12:26:22 <ais523> I didn't ever finish it
12:27:23 <wib_jonas> ais523: in all these cases, you make all the nodes immutable, as described in Chris Okasaki's book, you copy nodes instead of editing their links in place when you modify the trees, and this means to clone you can just copy a reference to the root node or similar
12:28:59 <ais523> right – it was hard to prevent the memory usage going quadratic with the things I was trying
12:29:09 <wib_jonas> finger trees are a variant of 2-3 trees that's more difficult to implement, but in exchange inserting or removing an element from either end can be done in amortized constant time instead of just logarithmic time. the Haskell standard library has a type Seq which implements this, giving a list with the properties that you're asking for, at least if
12:29:09 <wib_jonas> I understand what you need correctly
12:29:16 <ais523> and O(log n) probably isn't a disaster but I've become exceptionally perfectionist recently
12:29:25 <esolangs> [[User talk:Tommyaweosme]] M https://esolangs.org/w/index.php?diff=158317&oldid=158212 * None1 * (-916) The rotated comment covers content
12:31:10 <ais523> this is something of a weird case because most of the time, these lists are going to be quite small but could theoretically be large, so a theoretically perfect solution would probably start with a naive quadratic algorithm and switch to something more asymptotically efficient (but with worse constant factors) if the lists got larger
12:32:33 <esolangs> [[User talk:PrySigneToFry]] https://esolangs.org/w/index.php?diff=158318&oldid=158091 * None1 * (+428) /* Any interests on joining our Esolang Tencent QQ group? */
12:32:52 <ais523> but just knowing it's possible helps a lot because I don't have to worry about making sure the algorithm is possible to make efficient any more, I can write the algorithm and optimise it later
12:33:29 <wib_jonas> ais523: if they're usually small then you can store multiple logical nodes together in a memory node, like the lower few levels of a B-tree.
12:33:59 <ais523> they're usually small but I have lots of clones with only minor differences
12:34:17 <ais523> which makes condensing them into arrays hard
12:34:19 <wib_jonas> yeah, then you may have to benchmark what the right node size is
12:35:04 <ais523> like, abcd and abce and abcde might all coexist, and ideally the "abc" part of that would be shared to stop memory use going quadratic
12:35:51 <ais523> the algorithm I use this for is basically operating on stacks, and it usually pushes and pops onto one end of them, but a) it needs a history of all the previous stack states and b) occasionally one stack gets concatenated to another
12:38:54 <wib_jonas> since we're here I also have a data structure question. I want a key-value dictionary (rather than a sequence that keeps its order). I want it as a database on disk in which I can look up and update quickly. so far I could use a balanced tree or hash. but I'd also like a guarantee that if someone examines the data on disk they can derive no
12:38:55 <wib_jonas> information about the order in which the keys were inserted or anything else about the history (the "no information" can be in the cryptographic sense where it's like 2**-128 bits of information). I know how I can do this with a treap, and I heard legends that there are hash tables (called "commutative) that can do this too though I don't know how.
12:38:55 <wib_jonas> But here I'm more interested if there's any existing software implementation that can do this and that I can use, especially one that doesn't require an expensive license.
12:40:21 <wib_jonas> ... . you want this to implement an esoteric programming language that has something more general and crazier than unlambda's call-cc?
12:41:18 <ais523> actually no (I do have plans for such a language but this isn't part of it)
12:42:41 <ais523> I'm trying to work on an algorithm to convert NPDAs into DPDAs, which is impossible in general but possible in most practically useful cases
12:44:31 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158319&oldid=158316 * Elphan * (+183)
12:45:15 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158320&oldid=158319 * Elphan * (+121)
12:45:29 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158321&oldid=158320 * Elphan * (+1) /* Prints "hi" how many times you want= */
12:45:38 <ais523> and it works by trying to simulate all the possible states of the NPDA stack in parallel, and checking to see whether there's been a combinatorial explosion or not – so I have a lot of very similar stacks that all need to be stored at once
12:48:07 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158322&oldid=158321 * Elphan * (+228) /* Description */
12:48:12 <wib_jonas> oh, that might be interesting. we were talking some weeks ago about how to implement mutex locking in multi-threaded brainfuck. so I later had an idea, but I can't tell if it's right, so I was thinking that I should implement a verifying program that generates all the possible states of the system (two processors plus shared memory cells) and does
12:48:13 <wib_jonas> graph traversals on them to prove the properties that I want. the problem is, even if I write the program I wouldn't be confident that I'm checking the right thing, but it still helps. now this sort of locking would be much easier if you could just use nondeterminism (I think that may be kind of how transactional memory works), and if you could
12:48:13 <wib_jonas> eliminate the nondeterminism automatically then maybe you could automatically generate correct locking algorithms in an ordinary deterministic model.
12:51:06 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:52:35 <esolangs> [[User talk:Ais523]] https://esolangs.org/w/index.php?diff=158323&oldid=158163 * None1 * (+346) /* Can you prove computatioal class for esolang xVector? */ new section
12:56:33 -!- impomatic has joined.
12:57:31 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158324&oldid=158322 * Elphan * (+24)
13:04:33 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158325&oldid=158324 * Elphan * (+4)
13:06:22 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158326&oldid=158325 * Elphan * (-4)
13:08:04 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=158327&oldid=158299 * Elphan * (+13) /* A */
13:08:33 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=158328&oldid=158327 * Elphan * (+0) /* A */
13:10:58 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158329&oldid=158326 * Elphan * (+43)
13:13:02 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158330&oldid=158329 * Elphan * (+10)
13:35:57 <esolangs> [[XVector]] https://esolangs.org/w/index.php?diff=158331&oldid=157941 * Ais523 * (+3378) computational class (it's equivalent to a 1-counter machine, which doesn't have a category)
13:37:14 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158332&oldid=158330 * Elphan * (+34) /* Prints "hi" how many times you want */
13:37:22 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158333&oldid=158332 * Elphan * (+1)
13:41:34 <esolangs> [[User talk:Ais523]] https://esolangs.org/w/index.php?diff=158334&oldid=158323 * Ais523 * (+981) /* Can you prove computatioal class for esolang xVector? */ it's a one-counter machine
13:44:08 <esolangs> [[User talk:Ais523]] M https://esolangs.org/w/index.php?diff=158335&oldid=158334 * Ais523 * (+1) /* Can you prove computatioal class for esolang xVector? */ add missing closing parenthesis
13:45:27 -!- tromp has joined.
13:54:05 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158336&oldid=158333 * Elphan * (-76)
13:55:47 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158337&oldid=158336 * Elphan * (-173) /* Description */
13:57:50 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158338&oldid=158337 * Elphan * (-52) /* Syntax */
14:14:56 -!- wib_jonas has quit (Quit: Client closed).
14:26:45 -!- Sgeo has joined.
14:37:22 -!- impomatic has quit (Quit: Client closed).
14:47:57 <esolangs> [[Ampell]] https://esolangs.org/w/index.php?diff=158339&oldid=158338 * Elphan * (-218) /* Description */
14:51:53 -!- impomatic has joined.
15:03:04 <esolangs> [[FLOORPLAN]] N https://esolangs.org/w/index.php?oldid=158340 * B jonas * (+628) Created page with "'''FLOORPLAN''' is an esoteric programming language. == External link == * Peter Hebden, Anna Williams, Sofia Wolf, `FLOORPLAN`: The language of the future. [https://sigbovik.org/2025/proceedings.pdf (2024-04-04) ed. the Association for Computational Heresy, *a recor
15:03:37 <esolangs> [[FLOORPLAN]] https://esolangs.org/w/index.php?diff=158341&oldid=158340 * B jonas * (+11)
15:10:31 -!- ais523 has quit (Ping timeout: 244 seconds).
15:13:21 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:28:14 <esolangs> [[FLOORPLAN]] https://esolangs.org/w/index.php?diff=158342&oldid=158341 * B jonas * (+139)
15:37:00 -!- wib_jonas has joined.
15:39:38 <wib_jonas> SIGBOVIK 2025 p. 293 says that the name of their system is the character \u200D, but it also says that it's "named after the symbol used for function application", and I think the symbol they mean there is \u2061. Why would they give the former name if it's named after the latter? Weird.
15:41:39 <wib_jonas> Fortunately it's esoteric but not a language so I probably don't need to create a page for it on the esowiki and so don't have to decide what its name is.
15:42:24 -!- wib_jonas has quit (Quit: Client closed).
15:55:52 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158343&oldid=158303 * Hotcrystal0 * (+75)
15:59:44 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158344&oldid=158343 * Hotcrystal0 * (+192)
15:59:55 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158345&oldid=158344 * Hotcrystal0 * (+6)
16:01:13 -!- tromp has joined.
16:01:28 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158346&oldid=158345 * Hotcrystal0 * (-2)
16:03:38 <esolangs> [[User programmed]] https://esolangs.org/w/index.php?diff=158347&oldid=158346 * Hotcrystal0 * (+24) adding a category
16:06:48 <esolangs> [[Black]] https://esolangs.org/w/index.php?diff=158348&oldid=127271 * Hotcrystal0 * (+31) They say this is a cellular automaton disguised as an esolang
16:17:09 <esolangs> [[Talk:]] https://esolangs.org/w/index.php?diff=158349&oldid=155776 * Hotcrystal0 * (+276)
16:30:15 -!- FreeFull has joined.
17:01:06 -!- ais523 has joined.
17:02:45 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:09:55 <ais523> I don't know what I expected
17:10:23 <ais523> apparently it is ACTIVATE ARABIC FORM SHAPING
17:10:46 <ais523> and 200D is ZERO WIDTH JOINER, which is also useful for Arabic I think
17:10:47 <int-e> `` unidecode $(printf '\u206D')
17:10:49 <HackEso> [U+206D ACTIVATE ARABIC FORM SHAPING]
17:11:18 <int-e> `` unidecode $(printf '\u2061')
17:11:19 <HackEso> [U+2061 FUNCTION APPLICATION]
17:11:24 <int-e> `` unidecode $(printf '\u200D')
17:11:27 <HackEso> [U+200D ZERO WIDTH JOINER]
17:13:18 <ais523> hmm, we have invisible function application, invisible plus, invisible times, invisible comma
17:13:32 <ais523> but no invisible function *composition*
17:14:17 <ais523> now I'm wondering if it's even possible to write gf(x) to mean g(f(x)) – I think I've seen that notation somewhere but I can't remember where
17:14:27 <ais523> but of course invisible composition happens all the time in concatenative langauges
17:17:24 <ais523> I've been pondering how to implement finger trees in Rust – the type system gymnastics used to make them work are beyond even Haskell unless you turn on some extensions, so the whole "make invalid states unrepresentable" thing could be quite difficult
17:18:25 <ais523> I suspect the most efficient solution uses weak typing (i.e. non-disjoint unions), with functions given arguments to tell them what type they're supposed to be acting on and they interpret memory as that type
17:18:41 <b_jonas> ais523: soryr, I meant \u2061 and \u200D
17:18:52 <b_jonas> wait, where does 206D come from?
17:19:20 <ais523> me mixing up the two characters I think
17:19:31 <ais523> I either misread your comment, or miscopied the codepoints into IRC
17:20:20 <b_jonas> ais523: the one I'm missing is two different characters for invisible function composition depending on whether the function is on the left or right of its argument, but you can argue that the function can be on the right only if it's linear and then it's just an invisible multiplication
17:20:46 <ais523> which meaning of "linear" is this?
17:20:53 <int-e> b_jonas: there's always LTR and RTL ;-)
17:21:17 <int-e> (Just a reminder that Unicode is a horrific mess.)
17:21:28 <ais523> oh right! so I discovered that Arabic numerals were originally the correct way round (i.e. little-endian) – the least significant digit was on the right, but Arabic is a right-to-left language
17:21:47 <ais523> however, when they started being used in left-to-right languages, the order of the digits wasn't reversed to compensate for the different writing direction
17:21:57 <ais523> that's how we ended up with our numbers the wrong way round
17:22:15 <b_jonas> ais523: the one where the function is a monoid homomorphism from a monoid to another monoid (usually a group) with the monoid operation is written as multiplication (rather than addition)
17:22:42 <int-e> ais523: well there's also the roman numerals which put the higher-valued ones first
17:23:04 <int-e> "first" - to the left
17:23:06 <b_jonas> a special case could be a linear function mapping a (horizontal) vector to another (horizontal) vector in two vector spaces
17:23:16 <int-e> And what about the Babylonians? I don't even know.
17:23:29 <ais523> b_jonas: is this the same notation which writes the operation that produces a function type from a return type and argument type as exponentiation?
17:24:45 -!- tromp has joined.
17:24:57 <ais523> a few years of codegolf convinced me that little-endianness is correct, about the only time big-endian notations saved bytes was when solving challenges that were based on the way humans write numbers
17:25:46 <ais523> so now I have some likely-unknown person in medieval times to be annoyed at for messing up today's computer science
17:26:05 <int-e> big endian is nice for parsing numbers; little endian is nice for printing numbers
17:26:12 <b_jonas> ais523: re digit order, I don't know for sure but I suspect that's because al-Khwarizmi, who popularized decimal positional number system to use for arithmetic, didn't write the numbers inline in text, but as tables in displayed figures, so they didn't look like they're supposed to be words in rtl or ltr text
17:26:17 <int-e> and for arithmetic without base conversion
17:27:02 <int-e> > foldl (\x y -> x*10 + y) 0 [1,2,3]
17:27:32 <ais523> right, parsing is slightly more elegant big-endian
17:28:51 <ais523> oh wow, those FLOORPLAN authors are at the university I worked at for years
17:29:17 <b_jonas> ais523: no, there are three different orders: function on the left is what everyone but algebraists write (though algebraists can also write it), function on the right (algebraists use it when the function is linear), and function in the right superscript (when the function need not be linear)
17:29:32 <b_jonas> also my description about what linear means above is specifically incorrect
17:32:03 <ais523> hmm, I wonder if there is a name for matrices where every row and column contains one 1 (multiplicative identity) and the other elements are 0 (additive identity)? those would be linear in two senses at once
17:34:13 <b_jonas> so a linear unary function from a vector space to another vector space is a function f such that for any scalars α,β and vectors x,y, f(αx+βy) = αf(x)+βf(y). when a function is like that, an algebraist could write the function call f(x) as fx if they think of x as column vectors, or as xf if they think of x as a row vector. (row and column could be swapped depending on conventions, linear algebra
17:34:19 <b_jonas> has like five boolean dimensions of arbitrary notation conventions). if both vector spaces are finite dimensional then f can be imagined as a matrix and the function call is a matrix multiplication.
17:37:30 <b_jonas> algebraists can be more relaxed with this and generalize to other situations than just a linear function from a vector space to another.
17:38:15 <ais523> hmm, to me there seems to be a rule that if the function goes to the right of the argument, its name has to be a capital letter
17:43:50 <b_jonas> now a group homomorphism is a mapping f from a multiplicative group to another such that f(x)f(y)=f(xy). an algebraist can write such a function as a right superscript (exponent), as in instead of f(x) they write x↑f. the origin of this is that if you consider a conjugation with a group element c, defined as f(x)=c⁻¹xc then they write this as a superscript f(x) = x↑c. any conjugation is also a
17:43:56 <b_jonas> group homomorphism because (x↑c)(y↑c) = (c⁻¹xc)(c⁻¹yc) = c⁻¹xyc = (xy)↑c, and that's the same identity that exponentiation to a fixed integer power holds, and exponentiation was already written as a right supersript.
17:45:14 <b_jonas> and if there's a function that's none of these then an algebraist tries to pick whichever of f(x), fx, xf, x↑f makes the most sense, or might even use other less common notations
17:46:29 <b_jonas> like there's right superscript or right subscript for indexing a tensor or any sequence in general
17:46:47 <b_jonas> and notation can get wilder when a function has multiple arguments
17:52:14 -!- impomatic has quit (Quit: Client closed).
17:55:48 <ais523> fwiw, there are quite a few practical advantages to writing the argument first when doing a function call
17:56:04 <ais523> and lots of languges do object.method().method().method() partly because of that
17:57:27 <esolangs> [[User talk:Tommyaweosme]] M https://esolangs.org/w/index.php?diff=158350&oldid=158317 * Aadenboy * (+776) adding back the messages but removing the rotation transform
17:57:46 <ais523> is |> a builtin in Ocaml? I think it is but am not totally sure
17:58:23 <ais523> (it's like $ in Haskell but the argument comes before the function, and the associativity makes it chain properly, just like $ does)
18:06:34 <zzo38> Many programming languages already have RPN that you have to write the arguments before the function calls, although that is usually using the stack, which is not quite the same as a argument list.
18:07:08 <zzo38> I also believe that Unicode is a mess, but you can do something about it e.g. make a program that does not expect you to use Unicode.
18:08:58 -!- impomatic has joined.
18:13:02 <zzo38> And, roman numbers have a negative position as well.
18:13:24 <b_jonas> so anyway, literate programming has this thing where the same source code is both interpreted as a traditional programming language source code and printed documentation, but there are a few special transformations during the transformation, like some word are automatically written in bold or italic, and some two-character punctuation is formatted as a specific character. Eg. in C >= means greater
18:13:30 <b_jonas> equal, and in literate C it is formatted as ≥ ; and in Haskell ++ means list concatenation, and it's formatted as two plus signs overlapping horizontally with their vertical lines close to each other and the horizontal line incident.
18:19:52 <esolangs> [[User:RobinsAviary]] N https://esolangs.org/w/index.php?oldid=158351 * RobinsAviary * (+125) Created page with "Hi! I'm Robin from Robin's Aviary! I'm a programmer who is interested in making interpreters for various different esolangs."
18:20:12 <esolangs> [[User:RobinsAviary]] M https://esolangs.org/w/index.php?diff=158352&oldid=158351 * RobinsAviary * (+13)
18:21:34 <fizzie> Fun fact: |> is used in GoogleSQL's somewhat recently introduced "pipe query syntax", which allows writing some otherwise quite unwieldy, nested-subquery-heavy SQL queries in a more "flat" form: https://cloud.google.com/bigquery/docs/reference/standard-sql/pipe-syntax
18:21:52 <fizzie> For example, you could write `SELECT f(z) AS z, SUM(y) AS y FROM (SELECT z, SUM(w) AS w FROM foo GROUP BY z) WHERE f(z) > 0 GROUP BY z` as `FROM foo |> AGGREGATE SUM(w) AS w GROUP BY z |> EXTEND f(z) AS fz |> WHERE fz > 0 |> AGGREGATE SUM(y) AS y GROUP BY fz AS z`.
18:22:32 <fizzie> (Probably not the best example, but in practice for some actual queries that I can't share I've found it to be easier to follow.)
18:22:33 <ais523> I assume that EXTEND thing is part of the new syntax? I don't remember seeing it in SQL before
18:23:23 <b_jonas> and then Wolfram Mathematica decided to embrace this feature of literate programming and decided to take it further, allowing the programmer to write code that serves both as executable code and formatted as the sort of traditional mathematical notation that mathematicians are used to from traditional typography. so they added conveneitn ways to enter superscripts, subscripts, barred fractions, and
18:23:29 <b_jonas> surrounding square root signs, and stacked binomial coeff notation, and matrix writte as a 2d array of coefficients. And it also added lots of characters that mathematicians may use, like greek letters and ≥ and × but also four invisible infix operators. And I think that's why those four invisible characters are encoded in unicode.
18:24:40 <fizzie> Yeah, `EXTEND` basically adds extra columns to the conceptual result table. It's pretty much the same as `SELECT` except it implicitly selects all the existing columns too.
18:24:53 <b_jonas> fizzie: didn't WITH syntax already existed for that in SQL?
18:25:17 <b_jonas> maybe I don't understand what those SQL expressions that you gave as example mean
18:25:49 <ais523> the order in which you have to write things in standard SQL is weird
18:26:12 <ais523> I think many people have observed that it would make more sense to put the columns being selected at the end and the table at the start
18:26:13 <fizzie> `WITH` defines named temporary tables. I guess it does have some similarity, in that you can also use it to avoid deeply nested subqueries.
18:26:17 <HackEso> WITH`? No such file or directory
18:27:18 <zzo38> WITH can also be used for recursive queries
18:28:27 <b_jonas> ``` hg cat -r 12479 /hackenv/wisdom/password # this was the point when I kind of gave up about SQL syntax
18:28:31 <HackEso> The password of the month is OFFSET 0 ROW FETCH NEXT 50 ROW ONLY.
18:30:22 <b_jonas> the semantics of SQL mostly make sense so I like that, but the syntax is terrible. of course I also think that about C+= and Rust to some extent.
18:31:11 <fizzie> I did have a number of queries that had the form of `WITH foo AS (SELECT ... FROM original_source ...), bar AS (SELECT ... FROM foo ...), baz AS (SELECT ... FROM bar ...) SELECT ... FROM baz ...`, but the pipe syntax removes the need to even give names for all the intermediate steps, for that sort of linear sequence of consecutive operations.
18:31:25 <ais523> fwiw I actually prefer Rust's syntax to its semantics
18:32:12 <ais523> I am planning to write a very long article at some point as to why &mut is a misfeature (which sounds like a crazy statement, so I both need to back it up and present a viable alternative)
18:33:41 <zzo38> What does &mut mean in Rust?
18:34:48 <ais523> it is an exclusive reference: it's like a pointer to some memory but a) it's never null, b) it always contains a value of a particular type (and is statically checked to always contain a bit pattern that is valid for that type), and c) there's a compile-time-checked guarantee that nothing else will read or write the memory it points to until the reference ends
18:35:56 <ais523> …and now I'm wondering how you forcibly end an &mut in Rust – for almost anything you can specify when the lifetime ends with mem::drop but that doesn't work for &mut for… reasons
18:36:24 <ais523> I think it's the only non-Copy type for which that is true
18:39:11 <ais523> (the compiler is very good at inferring where it's supposed to end, though, so there is rarely a reason to end it manually)
18:39:20 <zzo38> (There are probably other misfeatures in Rust as well; I think the main string type using Unicode is a misfeature in many programming languages, and I also once saw someone claiming that the fact that the string must be validated is a misfeature. I think there are probably others as well. C also has misfeatures, including some syntax misfeatures like I mentioned before.)
18:40:19 <zzo38> I think that the compiler should not always have to guess, and that specifying things manually would probably be helpful anyways
18:40:21 <b_jonas> if you write that then I'll certainly want to read it
18:40:30 -!- impomatic has quit (Ping timeout: 240 seconds).
18:42:47 <zzo38> From what I understand of Rust (which is not much), such kind of exclusive references like that may be necessary to work with the general working of Rust, although that might itself be a problem, anyways, since maybe it is badly designed in general.
18:45:28 <fizzie> Fun optimization story from #c the other day. Someone had a piece of code along the lines of (streamlining a little here) `struct foo { short x, y; }; bool f(struct foo *p) { return p->x == -1 && p->y == -1 }`, and it turned out Clang creates better code for it when the parameter declaration is changed to `bool f(struct foo p[static 1]) { ... }`. Presumably because for the first one, it has to
18:45:30 <fizzie> account for the scenario where `p->x` is a valid memory reference but `p->y` isn't, so the short-circuiting semantics of && become load-bearing, while `[static 1]` guarantees that an entire full `struct foo` object is accessible through the pointer.
18:47:04 <ais523> zzo38: I do like the approach of "a string is at the language level a list of codepoints, and the application can choose what the codepoints mean" – Perl does that, and allows the codepoints to go up to 2³¹
18:47:28 <fizzie> (The generated code with the [static 1] parameter was also the moral equivalent of `(p->x & p->y) == -1`, which was kind of fun.)
18:47:42 <ais523> fizzie: apparently Rust has struggled with that sort of example in the past
18:48:44 <ais523> I read a blog post reading about how == on a struct with two fields didn't get optimised into one comparison at the time – then I tried it on a more recent version of Rust and it did
18:48:52 <ais523> so I wonder if it's putting in a [static 1] equivalent
18:49:37 <zzo38> ais523: I think that if you do that, then it should be useful to have a string type for 8-bit characters (which should probably the usual one) as well as one for 32-bit characters, and possibly also 1-bit characters is sometimes useful.
18:50:45 <zzo38> (Even in a string of 8-bit characters, you can have multi-byte characters and separate functions for dealing with them; for many uses this is probably the useful way to do it anyways, although there are also circumstances where having a type for a string of 32-bit characters is more useful.)
18:51:00 <ais523> processors have similar short-circuiting issues, e.g. the "loop" opcode is very slow on modern processors because it a) has to handle the case of the branch target being paged out, and b) has to handle the case of the branch target being paged out on the last loop iteration
18:51:33 <ais523> which can lead to an awkward case where cx gets decremented and then you have a page fault in the middle of the instruction
18:51:34 <b_jonas> fizzie: oh wow. so if I define such a structure I should declare it alignas(4) which guarantees that if x can be read then y can be read as well?
18:52:20 <ais523> modern processors would much prefer you to write dec cx; jnz label – because then they can handle the case of a page fault by just leaving the IP in between the two instructions
18:52:50 <ais523> (it's parsed as a single instruction by the front end – the long encoding is just there to allow the IP to be left in the middle)
18:52:50 <b_jonas> ais523: I think that could also depend on the known alignment of the struct
18:53:13 <ais523> b_jonas: I don't know whether or not compilers optimise based on "if any address on a cache line is readable, then the entire cache line is readable"
18:53:33 <fizzie> Yes, I think an alignment-based argument could also make it safe, although I was unable to convince Clang to make use of it.
18:53:38 <int-e> ais523: it's circular too (I like to use the word co-evolution): since basically nobody uses the `loop` instruction anymore there's no incentive to deal with the complication you mentioned efficiently in the processor.
18:53:42 <ais523> in particular, I don't know of an architectural guarantee that cache lines won't be smaller in the future
18:54:02 <zzo38> If pages with memory access permissions are required to be aligned (and the compiler knows this), then I should expect that specifying required alignment should be allowed to work?
18:54:06 <ais523> which means that it could technically be incorrect to assume that
18:54:13 <fizzie> Human-written code certainly does make that assumption sometimes.
18:54:37 <fizzie> Specifically, string function implementations that read past the '\0' when they know they're working on aligned data.
18:54:38 <ais523> I think there is a practical requirement to keep cache lines at at least 64 bytes, it would break a lot of code to make them smaller
18:55:06 <b_jonas> ais523: this would be an architecture-dependent optimization, but that's fine because it's also architecture-dependent if you want to optimize to a single 32-bit comparison
18:55:33 <ais523> b_jonas: right, the question is as to what future processors may be the same architecture but have different caching mechanisms
18:55:57 <b_jonas> and obviously you should declare the type that way only if you relaly can guarantee that it's aligned, you can't slap it onto an existing type because that can break ABI-compatibility
18:56:17 <zzo38> Is LOOP opcode sometimes used for stuff other than loops? (I had made VM codes that have a LOOP opcode and then often use it for stuff other than loops)
18:56:19 <ais523> there are lots of examples of this sort of thing, e.g. is a processor that returns 0 for bsr on 0 a valid x86-64 processor?
18:56:21 -!- impomatic has joined.
18:56:46 <int-e> ais523: thanks btw, I had not considered the fact that there's no point between decrementing the loop counter and the conditional jump to be a complication.
18:56:58 <ais523> (the Intel manual says it's undefined but Intel processors return the value that was in the output register beforehand, and AMD processors document it as returning the value that was in the output register beforehand)
18:57:44 <ais523> zzo38: it could be, but nowadays it's rarely used for anything but codegolfing because it's so slow
18:58:34 <int-e> But I do not see that it is *necessarily* a costly complication; among all the other speculation and instruction reordering it feels like a pretty small thing. But add the fact that nobody uses the instruction and it makes sense that you punt on dealing with it.
19:01:36 <fizzie> FWIW, I didn't get Clang to make it a 32-bit comparison even with [static 1]. It removed the branching needed to avoid evaluating the other half, but even so still read the data as two 16-bit words. It also generated worse code for comparing "arbitrary" values than the all-bits-one ones. Here's an illustration: https://gcc.godbolt.org/z/P55zWqrnj
19:02:52 <fizzie> (Also tried slapping an `__attribute__ ((aligned (4)))` on it, but that did nothing.)
19:03:55 <b_jonas> ais523: x86 in the broader sense does NOT guarantee that, because in 32-bit protected mode data segments that are less than 2**20 bytes long can have any length at byte precision. but x86-64 user mode guarantees trivial segmentation, so in x86-64 if part of any page (in the processor sense, not the operating system sense) is readable then the whole page is readable, and pages are 2**12 bytes or a
19:04:01 <b_jonas> multiple. an I/O device can break this but in C or rust you'd have to use a volatile read for those.
19:05:08 <int-e> Funny though... this week I rewrote an inner loop in assembly and it made it 2x faster. It was... unexpected. https://paste.debian.net/1376253/ (target is a Haswell processor)
19:07:17 <ais523> int-e: it's surprising to see how much more the compilers spilled than you
19:07:26 <int-e> yeah I thought so too
19:08:49 <esolangs> [[Brainfuck]] https://esolangs.org/w/index.php?diff=158353&oldid=126966 * Kaveh Yousefi * (+904) Introduced an examples section comprehending as its two incipial members a repeating cat program and a Hello, World! printer.
19:09:15 <ais523> one other weirdness is that the "lucky" g++ version appears to have multiple different targets to jump to from the loop, and the others have a single exit point
19:09:23 <b_jonas> fizzie: I'm never quite sure when x86 uses sign-extend versus zero-extend, but I think in your example code f2 which compares to -1 can use the shorter instruction encoding that has a one byte long immediate -1 in the instruction and sign-extends that to a short, and you can't do that when comparing to arbitrary
19:09:48 <esolangs> [[Brainfuck]] https://esolangs.org/w/index.php?diff=158354&oldid=158353 * Kaveh Yousefi * (+612) Added a hyperlink to my implementation of the Brainfuck programming language on GitHub and supplemented the Implemented category tag.
19:09:53 <int-e> I actually took it one step further too, unrolling the loop one more time, which doesn't help on haswell but I did find a processor that executes the resulting loop in 3.5 cycles per iteration (EPYC Rome).
19:10:44 <fizzie> Well, the -1 case also ands the two halves of the struct together and performs just one comparison, that only works in the all-bits-one case of -1.
19:11:02 <int-e> ais523: In the end I test each byte of the vector comparison individually. The "lucky" version omitted the bulk zero test and just does those individual ones.
19:11:57 <int-e> (each byte corresponds to one of the 8 byte values in the YMM register)
19:13:07 <int-e> ais523: That's actually why I even looked at the assembly code... I /knew/ the value would be 0 almost all the time, so I did if (!mask) continue; before testing the individual bytes. But for g++ that made the code slower and I had no idea why.
19:13:28 <ais523> int-e: ah, I see, you are over-reading
19:13:30 <int-e> value = resulting mask from the comparison
19:13:42 <ais523> in this case it shouldn't matter because you are over-reading from a set of integer registers
19:13:48 <ais523> but it may be hard for compilers to figure that out
19:14:17 <b_jonas> int-e: yeah, anything like strcmp/strscn/strlen that you implement with vpmovmskb is exaclty a kind of code where I would expect that writing it in assembly (or calling a lower level library function implemented in hand-written assembly) will help
19:15:16 <b_jonas> I guess this is more like strnscn
19:15:19 <int-e> ais523: anyway, I /tried/ to help the compilers by writing the exact inner loop I wanted but they still spilled the register contents all over the place.
19:15:27 <b_jonas> or strcscn or whatever it's called
19:15:28 <ais523> I eventually ended up finding a better algorithm, but for a while a program I was writing had a branch that was only 1 in 4 billion to be taken (it required an effectively random 32-bit number to have a particular value), and yet it had to be there for correctness
19:15:45 <int-e> Conclusion: Compilers still are kind of stupid, and *sometimes* it can really hurt.
19:15:51 <ais523> and I thought "I should probably put an unlikely annotation on this, once those get stabilised in Rust)
19:16:18 <ais523> (it would have mattered because the check was short-circuitable but it looked unpredictable to LLVM, so it didn't try to short-circuit)
19:19:53 <int-e> ais523: over-reading... vpmovmskb wants a 64 bit destination argument, and I wanted to let the compiler assign the register. I don't know whether there's a magic incantation to get %eax from %rax, nor whether that would make any difference
19:21:46 <int-e> Anyway. It's atypical code, and when I wrote the inline assembly I was hoping for maybe 20% faster code, not 2x faster. :-)
19:22:23 <int-e> (I had not actually computed cycle counts at that point, just observed a very high variance in runtime from different compiler outputs.)
19:23:25 <int-e> May I add that from a 90's person perspective the idea of executing 9 instructions in 2 cycles is insane. :-)
19:24:25 <Sgeo> The Thing King! https://en.wikisource.org/wiki/Paging
19:24:28 <Sgeo> I am easily amused
19:29:03 <int-e> Sgeo: So they implemented this in a Thing King Machine?
19:29:52 <ais523> <int-e> I don't know whether there's a magic incantation to get %eax from %rax, nor whether that would make any difference ← gcc has one of those for inline asm and I think Rust does too
19:29:53 <b_jonas> ais523: doesn't calling a #[cold] function work as an unlikeliness annotation? (or raising a panic, but that's probably not appropriate in your case.)
19:29:54 <int-e> (The timing doesn't quite work out: https://en.wikipedia.org/wiki/Thinking_Machines_Corporation was founded in 1983)
19:30:24 <ais523> b_jonas: probably, but it also has other side effects
19:31:31 <ais523> likely/unlikely/cold_path seem fairly close to stablisation, I think the main concerns were based around whether all three functions were needed and what exactly the semantics were
19:31:56 <ais523> I'm not sure how much discussion there was of whether an unpredictable was needed
19:41:18 <ais523> in general, though, compilers are very bad at vectorising things that are even slightly nontrivial and I'm not completely sure why
19:41:56 <ais523> I have plans to go the other way – a language in which you can *only* write code that vectorises well, and a compiler for it that gives guaranteed efficient vectorisation
19:44:50 <b_jonas> ais523: yeah, I was thinking of something like that, a low-level array programming language
19:45:22 <b_jonas> though that still leaves lots of choices open so I may be thinking of something very different from you
19:45:28 <ais523> right, I realised after a while that I was supposed to give it APLish semantics where the program is written as though it's a linear sequence of operations on arrays
19:45:46 <ais523> even though it optimises into a fused loop
19:45:54 <int-e> ais523: Ah. The keyword is "operand modifier". The particular incantation is that "%k0" gives you %eax when %0 is rax. Or "%h0" gives you %rax from %eax though I guess that's theoretically dangerous.
19:46:32 <ais523> int-e: writing to %eax zeroes the rest of %rax, so the theoretical danger could be avoided by setting the high part to 0 when you're done
19:47:03 <ais523> processor designers seemed to have realised that "writing to the low part of a register zeroes the high part" gradually
19:47:22 <ais523> *that "…" is more efficient
19:48:03 <ais523> although, something that confuses me – writing to an xmm register with SSE instructions leaves the high part of the corresponding ymm alone, whereas writing to it with AVX instructions zeroes the rest of the ymm
19:48:29 <ais523> but AVX and ymm were introduced at the same time, weren't they? so why even bother to give the older commands slow behaviour when mixed with the newer ones?
19:48:33 <int-e> anyway, testing just %eax makes no difference to the runtime here
19:48:56 <int-e> (I didn't expect any)
19:49:19 <ais523> hacks like vzeroupper were introduced to paper over the mess, but there are still a number of different ways that processors try to optimise it, none of which are really satisfactory, and it makes ABIs slower as well
19:50:01 <b_jonas> ais523: the problem is that there's a tradeoff here. if writing to the low part zeroes the high part, that's more efficient and easier to write ordinary functions in. but it also makes it harder to be compatible with a program written for an earlier version of the architecture, because when the older code tries to save and restore a callee-save register then it will accidentally zero the upper part of
19:51:10 <ais523> b_jonas: oh, I see, it's so that programs that use avx2 can call sse subroutines without breaking things, if there are call-preserved vector registers
19:51:55 <ais523> but, I think that combination is normally forbidden anyway because processors are so slow at doing the register merge – the x86-64 ABI bans letting SSE code ever see the high half of a ymm as nonzero
19:52:07 <b_jonas> this is why in x86, the SSE2 instructions don't change the high part of YMM registers, but the similar AVX instructions that still act on just the lower 16 bytes of a YMM register zero the upper part of the YMM register, because any compiler that emits the AVX encoding knows how to save and restore all 32 bytes
19:52:09 <int-e> ais523: an unlikely annotation does help clang out quite a bit; g++ doesn't do anything useful with it.
19:52:17 <ais523> meaning that you have to call vzeroupper on function return if you use any avx2, and in turn meaning avx2 registers can't be call-preserved
19:52:38 <ais523> right, I see the reasoning
19:52:44 <ais523> compatibility at the cost of performance
19:53:03 <int-e> clang manages to produce a 3 cycle version of the inner loop with the annotations.
19:53:09 <ais523> but the compatibility cases got soft-banned by the people who standardised the ABI
19:54:29 <int-e> and I guess https://paste.debian.net/1376259/ looks decent; no more spills
19:55:04 <ais523> oh, it's an integer addition, not a pointer addition
19:55:10 <ais523> it's just using the pointer addition command
19:55:20 <b_jonas> ais523: yes, but that "soft-banned" just means that YMM registers can never be callee-saved, even though you could probably write/compile more efficient code if you had a few callee-saved ones
19:55:40 <ais523> the use of %rbp caught me out because I initially assumed it was on a really big stack frame
19:55:48 <int-e> related to the loop upper bound
19:55:54 <ais523> but of course that would use a negative numbr
19:56:27 <b_jonas> MMX was even worse in this respect, but fortunately nobody wants to use MMX much anyway for other reasons too, so it doesn't matter
19:56:43 <ais523> the use of xor rather than cmp is really weird, even though it shouldn't matter – I assume that's for the benefit of the code after the loop
19:57:09 <ais523> I think MMX is top of the list of "never use this vectorising mechanism" for most people who hand-vectorise
19:57:33 <int-e> ais523: I'm missing two more instructions: https://paste.debian.net/1376260/
19:57:44 <b_jonas> no, technically 3Dmax is on the top of that list
19:58:07 <b_jonas> but that's kind of cheating
19:58:10 <int-e> and /previously/ clang++ combined the two conditions into a single one and the arithmetic looked vaguely complex enough for that
19:58:12 <ais523> didn't a few 3Dmax! instructions get stolen and become part of some other instruciton set?
19:58:28 <ais523> hmm, or was it called 3Dnow! ?
19:58:38 <int-e> 3Dnow! was a thing
19:58:40 <b_jonas> so irrelevant that I don't even remember its name
19:58:56 <b_jonas> does it really have an exclamation mark like CorelDraw! and Irregular Webcomic!?
19:59:13 <ais523> yes (just looked it up)
19:59:41 <int-e> ais523: it is kind of funny that that `lea` is in there... it could be done outside of the loop
20:00:56 <int-e> and I guess those two lea-s make the difference between 3 cycles and 2 cycles
20:01:06 <ais523> looks like MMX is integer arithmetic and 3Dnow! is float arithmetic, both in mm registers
20:03:06 <ais523> int-e: there are 10 instructions there and most modern Intel compilers decode at the rate of 4 per cycle, so that would explain the 3-cycle performance
20:03:16 <int-e> g++ does this and I don't even know where it found so many registers to add 4 to in the inner loop. https://paste.debian.net/1376262/
20:03:34 <int-e> ais523: you meant CPUs :)
20:04:27 <b_jonas> nice, that could be funny for legal problems as in https://www.youtube.com/watch?v=_8xhdL8BPvU&t=427s “Side note. I particularly enjoyed how since the title of <i>Sharks!</i> includes an exclamation mark, so too must all these legal documents, which was funny every time I read it. SHARKS!”
20:05:14 <int-e> ais523: Hmm, do you know whether the x86_64 ABI requires the upper 32 bits to be 0 for 32-bit values passed in registers?
20:05:29 <int-e> (otherwise I'll check)
20:05:40 <int-e> (SysV ABI of course)
20:05:40 <ais523> int-e: I did once but can't remember
20:06:03 <b_jonas> ais523: I don't think they can decode 4 instructions per cycle when there's so many vector instructions involved, and it shouldn't matter in a short inner loop because the decoded form will be cached in like two or three different ways
20:07:35 <b_jonas> int-e: check in Agner's documentation, that's more readable than the original ABI descriptions
20:08:43 <ais523> ouch, apparently the SysV ABI says that for booleans, the bits above the bottom 8 are unspecified when used as an argument or return value, but the high 63 bits have to be 0 in other situations
20:08:57 <ais523> I'm not sure what the difference is or even what other situations might matter
20:09:49 <ais523> b_jonas: indeed, caching is possible – I was wondering whether it might also be bottlenecked by compute units, but it's hard to calculate that in my head
20:10:11 <ais523> on Intel there are four compute units but not all of them can handle all operations (and one of them only does very simple integer arithmetic like adds and compares)
20:13:41 <ais523> int-e: so I've checked twice and haven't seen where the ABI talks about the high bits of registers, except for booleans and long double
20:16:54 <ais523> <ais523> I'm not sure what the difference is or even what other situations might matter ← I figured it out, if there are so many arguments that booleans have to be passed using the stack, they're given 8-byte stack slots and those have to be encoded as 0LL or 1LL
20:19:02 <int-e> ais523: Yeah I don't see any guarantee either so I guess the top bits are arbitrary.
20:20:23 <b_jonas> int-e: if you want to write a boolean into a GP register or memory word, you'll often do it with the 386 SETcc instructions, and those write just one byte, whereas if you're returning a 32-bit integer into a register you'll usually write it with an instruction that zeroes the upper 32 bits
20:20:33 <ais523> compilers seem to generate code that makes no assumptions about the top bits of the arguments that functions receive
20:20:46 <ais523> b_jonas: did you mean to ping me there
20:21:26 <b_jonas> yeah, you ais523 brought up the booleans specificaly
20:24:06 <int-e> b_jonas: Yes I realize that the upper half is *usually* cleared anyway because that's what the CPU does (to reduce data dependencies).
20:24:07 <ais523> do we have a HackEso command to convert asm to machine code?
20:24:26 <ais523> `` ls -1 bin/ | grep as
20:24:44 <ais523> `` ls -1 /hackenv/bin/
20:24:46 <HackEso> \ \ \ ! \ " \ # \ ' \ ( \ : \ ? \ ?? \ @ \ ^.^ \ ` \ `^ \ `` \ ¿ \ ؟ \ ⁗ \ 🌱 \ `̀ \ welcome \ ,1 \ 1 \ 13 \ 1492 \ ,2 \ 2 \ 2014 \ 2015 \ 2016 \ 2017 \ 3 \ 4 \ 5 \ 5quote \ 5w \ 8-ball \ 8ball \ aaaaaaaaa \ acronym \ addquote \ addscowrevs \ addtodo \ addwhatis \ age \ aglist \ airport \ airport-lookup \ allquotes \ analogy \ anonlog \ append \ as86 \ as-encoding \ asm \ asmbf \ asmbfx \ autowelcome \ bconv \ beat \
20:25:14 <ais523> `` cat /hackenv/bin/as-encoding
20:25:15 <HackEso> echo "$1" | as -o /tmp/out.o - && objdump -d /tmp/out.o | grep -P '^ *[0-9a-f]+:' | sed 's/^[^\t]*\t//; s/ *\t/: /g'
20:26:01 <ais523> `as-encoding prefetch (%rsi)
20:26:23 <ais523> OK, so that *was* a 3Dnow! instruction, but apparently the encoding was changed
20:26:35 <ais523> to no longer be in the 3Dnow! namespace
20:37:48 -!- visilii_ has joined.
20:37:54 -!- visilii has quit (Ping timeout: 268 seconds).
21:00:53 <esolangs> [[Talk:CAPI]] https://esolangs.org/w/index.php?diff=158355&oldid=155039 * Tommyaweosme * (+202)
21:01:34 <esolangs> [[Talk:CAPI]] M https://esolangs.org/w/index.php?diff=158356&oldid=158355 * Tommyaweosme * (+21)
21:04:10 -!- sprock has quit (Remote host closed the connection).
21:07:23 <esolangs> [[Countable infinity is uncountable infinity]] N https://esolangs.org/w/index.php?oldid=158357 * Tommyaweosme * (+402) Created page with "If we write all the numbers big-endian, like 0,1,2,3,4,5,6,7,8,9,01,11,21... then put a decimal point before it and put all the numbers before that, like 0.0, 0.1, 0.2... 0.01, 0.11.. 1.0, 1.1... then since infinity squared is stil
21:07:38 <esolangs> [[Countable infinity is uncountable infinity]] M https://esolangs.org/w/index.php?diff=158358&oldid=158357 * Tommyaweosme * (+20) category
21:08:12 <esolangs> [[Countable infinity is uncountable infinity]] M https://esolangs.org/w/index.php?diff=158359&oldid=158358 * Tommyaweosme * (+10)
21:09:03 <esolangs> [[Talk:Countable infinity is uncountable infinity]] N https://esolangs.org/w/index.php?oldid=158360 * Ais523 * (+370) explain why this is wrong
21:10:18 <esolangs> [[Talk:Boltzmann brainfuck]] https://esolangs.org/w/index.php?diff=158361&oldid=158309 * Tommyaweosme * (+361)
21:27:59 <esolangs> [[Talk:Countable infinity is uncountable infinity]] https://esolangs.org/w/index.php?diff=158362&oldid=158360 * Tommyaweosme * (+364)
21:30:23 <int-e> ...another person confused by the difference between "arbitrarily long" and "infinitely long"
21:30:26 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:30:51 <int-e> but I hate for it to take place on a wiki of all places
21:31:11 <esolangs> [[Talk:Countable infinity is uncountable infinity]] https://esolangs.org/w/index.php?diff=158363&oldid=158362 * Ais523 * (+303) p-adic numbers are only countable due to repeating if you include nonrepeating numbers in the same style, there are uncountably many
21:31:23 <int-e> s/take place/happen/ (hate the word near-duplication)
21:34:11 <esolangs> [[Talk:Boltzmann brainfuck]] https://esolangs.org/w/index.php?diff=158364&oldid=158361 * Int-e * (+128) scnr
21:35:08 <int-e> (I really shouldn't have because it'll just act as troll fodder.)
21:44:26 -!- ais523 has quit (Quit: quit).
21:45:14 <esolangs> [[Game of Life]] https://esolangs.org/w/index.php?diff=158365&oldid=154058 * Corbin * (+222) /* History */ Context for Gosper's 1970 construction, as related by Conway to Simon Peyton Jones.
21:59:18 <b_jonas> int-e: hold on, let me grab my mono-white infinite lifegain combo deck
22:07:53 <HackEso> olist <https://www.giantitp.com/comics/oots1326.html>: shachaf oerjan Sgeo boily nortti b_jonas Noisytoot
22:09:37 <Sgeo> I saw it, but completely forgot about olisting
22:12:43 <Sgeo> Trying to recall when I've did pseudomathy stuff. Um, believing 2/0 = 4/0 != 3/0, shortly before instead watching all x/0 except 0/0 collapse into the same thing.
22:13:44 <Sgeo> Trying to define a number @ such that |@| = -1, but |x| is a ... definitions thing, not so much a function that can be easily extended to new kinds of numbers without definitions anyway, I... think?
22:51:35 -!- sprock has joined.
23:14:24 <esolangs> [[User:Tommyaweosme/awesomenet website format]] N https://esolangs.org/w/index.php?oldid=158366 * Tommyaweosme * (+584) Created page with "awesomenet website format (awf) is a modified version of html used for awesomenet (found at https://docs.google.com/document/d/1sOSj-Gv6Kyu4DLou2aGoTioKh7beHmfx_fe5kCCsRUM/edit?usp=sharing). == commands == <h<b></b>1>a</<b></b>h1
23:20:49 <esolangs> [[Talk:Countable infinity is uncountable infinity]] https://esolangs.org/w/index.php?diff=158367&oldid=158363 * Tommyaweosme * (+231)
23:21:37 <esolangs> [[Countable infinity is uncountable infinity]] https://esolangs.org/w/index.php?diff=158368&oldid=158359 * Tommyaweosme * (+101)
23:32:01 <esolangs> [[User:Tommyaweosme]] https://esolangs.org/w/index.php?diff=158369&oldid=158202 * Tommyaweosme * (+30)
23:42:14 -!- amby has quit (Remote host closed the connection).