00:04:23 -!- Soni has quit (Ping timeout: 258 seconds).
00:26:51 <esolangs> [[Special:Log/newusers]] create * Potato Imaginator * New user account
00:28:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
00:40:39 -!- littlebobeep has joined.
00:50:57 -!- Lord_of_Life has quit (Ping timeout: 256 seconds).
00:52:36 -!- Lord_of_Life has joined.
01:10:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
01:15:10 -!- littlebobeep has joined.
01:43:25 -!- Soni has joined.
02:23:48 -!- HackEso has quit (Ping timeout: 276 seconds).
02:24:24 -!- HackEso has joined.
02:32:51 -!- tswett has joined.
02:33:50 <tswett> So as per usual, I've been feeding IRC logs into a neural net in order to generate new random chat.
02:34:45 <tswett> The neural net apparently randomly generated a really interesting Haskell expression. The neural net has someone writing:
02:34:46 <tswett> > let p = 1 : zipWith (+) (map (*4) p) (map (sum . zipWith (*) p . reverse) (inits p)) in p !! 20
02:36:23 <tswett> Welp, I searched the logs for that month and that expression is actually one that shows up nearly verbatim several times. It's not something that the neural net invented at all.
02:36:27 <tswett> My disappointment is immeasurable.
02:36:33 <tswett> Also, /// is called Slashalash now.
02:36:43 <tswett> How are all y'all doing?
02:39:48 <Corbin> Hm. Is it maybe a Project Euler answer? It looks familiar.
02:40:29 <tswett> Here are the first 21 elements of that list: 1,4,17,76,354,1704,8421,42508,218318,1137400,5996938,31940792,171605956,928931280,5061593709,27739833228,152809506582,845646470616,4699126915422,26209721959656,146681521121244
02:41:07 <tswett> Aha, it's this: https://oeis.org/A005572
03:01:11 -!- Taneb has joined.
04:02:32 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98329&oldid=98320 * PixelatedStarfish * (+21)
04:07:41 <zzo38> I think there is water to the east of England? Well, in the story in this role playing game that I do, there is a maze of canyons and then another country and then water. Also they play dice like in our medieval England but the main number is not restricted to the range 5 to 9, but if the main number is seven still has the highest probability of winning.
04:10:02 <Corbin> fungot: Is there water to the east of England?
04:10:02 <fungot> Corbin: an eu interest, or that the government will
04:32:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
04:35:14 -!- littlebobeep has joined.
05:05:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
05:12:49 -!- littlebobeep has joined.
05:18:18 <river> tswett: Wow your AI is actually intelligent and *understands* how to write haskell!
05:22:24 * Corbin imagines a line of dominos
05:32:08 -!- tswett has quit (Ping timeout: 252 seconds).
05:41:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
05:47:56 -!- littlebobeep has joined.
06:15:27 -!- chibi has joined.
06:26:54 -!- HackEso has quit (Ping timeout: 276 seconds).
06:27:09 -!- HackEso has joined.
06:38:32 <zzo38> (I did not actually write the rules for this variant dice game, although it should be written so that it works like the actual dice game if the main is 5-9, works similarly with other mains, and that the main being 7 still has the highest probability of winning.)
06:40:43 <zzo38> (In the modern game of dice, the main number is always seven, but the older game allowed other numbers too.)
06:46:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
06:48:16 -!- littlebobeep has joined.
07:06:16 -!- littlebo1eep has joined.
07:08:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
07:20:51 -!- littlebobeep has joined.
07:24:34 -!- littlebo1eep has quit (Ping timeout: 240 seconds).
07:25:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
07:26:00 -!- littlebobeep has joined.
07:27:17 -!- Sgeo has quit (Read error: Connection reset by peer).
07:33:17 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=98330&oldid=98323 * Potato Imaginator * (+177) /* Introductions */
07:43:36 -!- tromp has joined.
07:46:10 <esolangs> [[User:Potato Imaginator]] N https://esolangs.org/w/index.php?oldid=98331 * Potato Imaginator * (+89) Created page with "'''Potato Imaginator''' is YouTuber who creates videos on Programming , Animations , etc."
08:49:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
09:11:04 -!- littlebobeep has joined.
09:16:39 <esolangs> [[OW-1]] N https://esolangs.org/w/index.php?oldid=98332 * Potato Imaginator * (+3235) Created page with "'''OW-1''' is a two-dimensional programming language invented by on 12 June 2022 by [[User:Potato Imaginator]]. It is inspired from [[Befunge]] and [[Assembly_language]]. OW a..."
09:18:40 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=98333&oldid=98271 * Potato Imaginator * (+11) /* O */
09:22:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
09:23:30 -!- __monty__ has joined.
09:23:44 -!- littlebobeep has joined.
09:24:55 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98334&oldid=98332 * Potato Imaginator * (+125) /* External Resources */
09:27:52 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98335&oldid=98334 * Potato Imaginator * (+19) /* Commands */
09:30:22 <int-e> why gcc, why? https://paste.debian.net/1243926/
09:30:32 <esolangs> [[User:Potato Imaginator]] https://esolangs.org/w/index.php?diff=98336&oldid=98331 * Potato Imaginator * (+31)
09:30:55 <int-e> I meant "why, gcc, why?"
09:36:05 <int-e> ah, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620 helps... there's a flag -mcmodel=large
09:37:29 <int-e> Though that bug claims to be "fixed for GCC 11" and my gcc is 11.3.0.
09:40:00 <int-e> But whatever... the important thing is that the flag works
09:41:23 -!- tech_exorcist has joined.
10:01:46 <b_jonas> uh... a 2<<32 byte long static array
10:02:14 <b_jonas> I'm not surprised that it errors out, though probably the compiler stage should give an error rather than leave it to the linker
10:02:22 <b_jonas> since it's a single big array
10:17:29 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
10:18:38 -!- tromp has joined.
10:49:46 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98337&oldid=98335 * Potato Imaginator * (+5) /* Commands */
10:50:50 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98338&oldid=98337 * Potato Imaginator * (-4) /* Description */
10:51:00 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98339&oldid=98338 * Potato Imaginator * (+4) /* Description */
10:51:28 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98340&oldid=98339 * Potato Imaginator * (+1) /* Description */
10:55:02 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98341&oldid=98340 * Potato Imaginator * (+18) /* External Resources */
11:38:20 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:16:10 -!- sprout has quit (Ping timeout: 258 seconds).
12:30:17 -!- sprout has joined.
12:34:28 -!- definitelya has joined.
12:51:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
13:01:54 -!- tromp has joined.
13:53:44 -!- littlebobeep has joined.
14:03:24 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98342&oldid=98341 * Potato Imaginator * (-4)
14:04:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
14:11:31 <esolangs> [[OW-1]] https://esolangs.org/w/index.php?diff=98343&oldid=98342 * Gapples2 * (+336) computational class update
14:13:10 <esolangs> [[BitFlip]] https://esolangs.org/w/index.php?diff=98344&oldid=89862 * ChuckEsoteric08 * (+109)
14:25:11 <esolangs> [[Talk:OW-1]] N https://esolangs.org/w/index.php?oldid=98345 * Potato Imaginator * (+226) Created page with "Could Someone verify the Turing Complete Proof by actually running it in the program [https://tic80.com/play?cart=2840 Link] and verifying it. ~~~"
14:37:20 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98346&oldid=98329 * PixelatedStarfish * (-21)
14:37:43 <esolangs> [[OW-1]] M https://esolangs.org/w/index.php?diff=98347&oldid=98343 * Gapples2 * (+58) very small change
14:39:46 <esolangs> [[OW-1]] M https://esolangs.org/w/index.php?diff=98348&oldid=98347 * Gapples2 * (+4) even smaller change
14:41:12 -!- Sgeo has joined.
14:45:09 <esolangs> [[Talk:OW-1]] https://esolangs.org/w/index.php?diff=98349&oldid=98345 * Gapples2 * (+379) verified
14:50:25 <esolangs> [[Uyjhmn n]] https://esolangs.org/w/index.php?diff=98350&oldid=85240 * ChuckEsoteric08 * (+620) Turing completness Proof
15:18:21 <esolangs> [[User:ChuckEsoteric08]] https://esolangs.org/w/index.php?diff=98351&oldid=97534 * ChuckEsoteric08 * (+416) Improved page
15:21:04 <esolangs> [[User:ChuckEsoteric08]] https://esolangs.org/w/index.php?diff=98352&oldid=98351 * ChuckEsoteric08 * (+13)
16:13:07 <esolangs> [[1 Line Challenge]] https://esolangs.org/w/index.php?diff=98353&oldid=93530 * PixelatedStarfish * (+4) /* External links */
16:15:31 -!- perlbot has quit (Read error: Connection reset by peer).
16:16:14 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98354&oldid=98346 * PixelatedStarfish * (-190) /* The Refer Operator (&) */
16:17:20 -!- perlbot has joined.
16:18:22 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98355&oldid=98354 * PixelatedStarfish * (-104) /* Multiple Address Output */
16:25:47 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:29:29 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98356&oldid=98355 * PixelatedStarfish * (+516) /* Sources */
16:30:32 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98357&oldid=98356 * PixelatedStarfish * (-1) /* =Updates */
16:31:43 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98358&oldid=98357 * PixelatedStarfish * (+39) /* Updates */
16:35:12 <Sgeo> I'm confused about this code
16:35:25 <Sgeo> outport(SEQU_ADDR, 0x0F02);
16:36:04 <Sgeo> memset(vga+1, 0, 0xffff); /* stupid size_t exactly 1 too small */
16:38:48 -!- tromp has joined.
16:38:57 <int-e> Hmm, been a while. That... enables writes to all four memory planes?
16:40:02 <int-e> Sgeo: the thing to understand is that this write '02' to the sequencer index register, and then 0f to the sequencer data register... that's how x86 handles writing words to the port address space
16:40:25 <Sgeo> I'm glossing over that and wondering about that size_t complaint
16:40:36 <int-e> 16 bit memory model
16:40:37 <Sgeo> Is VGA really just one byte larger than convenient?
16:40:51 <int-e> it depends on what you're doing with it
16:41:27 <int-e> if it's just plain graphics then that's overkill. but if you want to scroll around, you'll be wrapping around on the four 64kb planes.
16:41:53 <Sgeo> This is inside a function called set320x200x256_X
16:43:00 <int-e> and if you don't want to scroll around you probabily would use the weird plain interleaved graphics mode with a single 320x200 = 64000 bytes buffer that's stored in all four planes rather than the "X" mode that doesn't do that.
16:45:40 <shachaf> How strong is the connection between prefix-free encodings of natural numbers and fast-growing hierarchies?
16:45:59 <int-e> weak enough that I'm not aware of it
16:46:55 <int-e> for whatever *that* is worth... I've seen slow and fast-growing hierarchies but never done much with them myself
16:47:34 <shachaf> Here are some classic encodings:
16:47:39 <shachaf> Encode n in unary (e.g. n 1s followed by a 0).
16:48:03 <shachaf> Encode log n in unary, then n in binary.
16:48:19 <shachaf> Encode log log n in unary, then log n in binary, then n in binary. Etc.
16:48:29 <int-e> log*: 0 | 1 <length-1, encoded> <bits>
16:48:50 <shachaf> Repeat the above k times for any k. Then you can encode k in unary instead of having it be constant, and so on.
16:49:04 <river> that's like ordinals
16:49:27 <shachaf> One way to think of these things is as binary search where you don't know the upper bound.
16:49:50 <shachaf> The first one is just linear search. The second one is repeated doubling to find an upper bound, then a binary search.
16:50:27 <shachaf> The third one is searching for an upper bound of the form 2^2^n, then binary searching exponents to find a bound of the form 2^n, then binary search for the number.
16:51:08 <shachaf> And presumably you can have a fast-growing hierarchy of functions to do the first step, searching for an upper bound.
16:52:46 <int-e> If you overdo it the encoding will suck for small numbers.
16:54:00 <river> to get wins representing big numbers
16:54:05 <shachaf> Yes, certainly these are all only interesting asymptotically.
16:54:07 <river> is there a way to measure the finite payoff
16:54:35 <river> payoff is probably a bad word
16:54:43 -!- ais523 has joined.
16:55:08 <shachaf> The first few I listed use n, O(log(n)), log(n) + O(log^2(n)), log(n) + log^2(n) + O(log^3(n)) bits.
16:55:17 <ais523> Sgeo: re: size_t, the issue is that when you're dealing with 64KiB segments, resonable sizes for things range from 0 to 65536, but that's 65537 possibilities
16:55:43 <ais523> Rust solves this problem with two different range operators: 0..65536 loops over 65536 possibilities (inclusive lower endpoint, exclusive higher endpoint)
16:56:07 <ais523> and 0..=65535 loops over all 65536 possibilities, including both endpoints
16:56:32 <ais523> zzo38: there is indeed water to the east of England, at least some parts of it, I confirmed this personally yesterday
16:58:05 <Sgeo> ...oh, memset(foo, 0, 0) is meaningless I guess. Need number of bytes to be 1. So it's like there's an unused size
16:58:30 <Sgeo> not meaningless but useless
16:59:02 <ais523> it is surprisingly hard to do an endpoint-inclusive loop over the entire range of an unsigned integral type in C
16:59:38 <ais523> you have to do something like "size_t i = 0; do { a[i] = 0; i++ } while (i != 0);"
16:59:55 <river> that's a nice way to do it
17:06:25 <int-e> you could also use word-based access and sidestep the issue that way
17:11:12 <fizzie> Hmm. I was kind of thinking the way the x86 REP prefix solved that issue was to also "redefine" what 0 means (or equivalently, test the counter only after the first decrement) but the manual's pseudocode suggests that is not the case, so maybe that was just a dream.
17:12:21 <int-e> fizzie: `rep` and `loop` are different in this regard
17:12:58 <int-e> (for a good reason, in the case of `loop`)
17:13:24 <int-e> (and, I suppose, also in the case of `rep` because 0-sized memory moves will be a common corner case)
17:13:37 <int-e> s/moves/operations/
17:14:14 <ais523> `loop` is weird; many modern processors run `loop` slowly but parse `dec rcx; jnz label` as a single instruction internally that has the same effect and is more efficient
17:14:16 <HackEso> loop`? No such file or directory
17:15:10 <ais523> I've seen a rumour that the reason is in order to get exception handling correct – if the jump points to non-executable memory, the latter sequence lets you leave the IP pointing at the jnz instruction, so that the instruction does the right thing when resumed after the exception is handled
17:15:31 <ais523> so the encoding of an instruction with `loop`-like semantics needs to end with the encoding for a `jnz` instruction, in order to be implemented efficiently
17:15:50 <ais523> whereas, with `loop`, the only way to get exception handling to work is to undo the decrement of rcx, which needs special cases
17:16:21 <int-e> And I suppose compilers never bothered to take advantage of `loop`. So CPU designers had no incentive to make it fast.
17:16:46 <shachaf> It would be funny if the encoding was such that you could jump into the middle of a loop instruction to get the jnz behavior.
17:17:13 <shachaf> I guess you might lose the benefits of the loop encoding being compact, though.
17:17:26 <ais523> maybe "lock jnz" should be introduced as an alternative encoding for "loop" – that's compact and might be unused at the moment
17:17:57 <ais523> although "dec rcx" is only one byte longer than "lock" on x86_64, and the same length on i386
17:17:59 <int-e> does x86_64 still have this instruction or has it been repurposed the way that the single byte inc and dec instructions were?
17:18:08 <ais523> (err, "dec ecx" on i386, obviously)
17:18:16 <ais523> int-e: it still has "loop" I think
17:18:22 <int-e> and, much earlier... I think `pop cs` was a thing on the original 8086?
17:18:40 <ais523> still has "lock" too, although it's been repurposed as a general-purpose prefix that changes the meaning of an instruction
17:18:58 <ais523> right, "pop cs" got repurposed very early because it is a very hard instruction to use correctly
17:19:00 <int-e> hasn't `lock` always been a prefix?
17:19:18 <ais523> yes, but it hasn't always had the behaviour of changing instruction semantisc
17:20:49 <ais523> "rep"/"repne" are similar, but they are no-ops on operations which don't have defined semantics changes (as opposed to "lock", which throws #UD, i.e. SIGILL, if it doesn't have a defined way to apply to that instruction)
17:21:45 <int-e> leading to some weirdness around `rep ret` a while ago, I forgot why that was a thing.
17:21:56 <ais523> really, x86 family instruction encoding is all-around a mess and programs would be more compact (saving memory bandwidth and L1C cache) if it were rethought
17:22:27 <ais523> int-e: oh, that one's because some AMD processors don't store the lowest bit of each instruction address in the branch predictor
17:22:38 <ais523> because almost all jumping instructions are at least two bytes long
17:22:52 <int-e> ah, thanks... that makes sense (sadly).
17:23:07 <ais523> shachaf: level 1 cache for code
17:23:16 <ais523> most modern processors have L1C, L1D, L2, L3 as their caches
17:23:22 <shachaf> Yes, I just always heard it called L1I.
17:23:55 <ais523> int-e: I might have forgotten the exact reasoning, but it's definitely something to do with having jumps happen more often than one per two bytes
17:26:03 <ais523> int-e: here we go, there's a full blog post about it: https://repzret.org/p/repzret/ (I was essentially correct, but not quite)
17:27:17 <int-e> I think the 16 bit x86 code was actually compact. With the 32 bit mode they started adding prefixes... though I guess the default based on execution mode helped to make them relatively infrequent. with x86_64 that's no longer true.
17:27:58 <ais523> yes, the problem is that it's trying to be backwards-compatible with something that has different optimization considerations
17:28:27 <ais523> 16-bit x86 basically reserves one bit in opcodes to distinguish between 8-bit and 16-bit instructions
17:28:53 <ais523> 64-bit x86-64 would want to reserve two bits in opcodes to distinguish between 8/16/32/64-bit instructions, but that bit isn't available because of the backwards compatibility concerns
17:29:24 <ais523> (the second bit besides the one that's already there)
17:30:01 <int-e> I guess we should be grateful that they at least gave us 8 extra registers for the longer encoding
17:31:02 <int-e> (except if you're a kernel developer and worry about context switch times... but the x86 state that needed to be saved was already very big anyway; the FPU extensions are the bigger offenders here)
17:31:57 <ais523> AVX512 has 32 512-bit registers, that's a lot more state to save than another eight 64-bit registers
17:36:09 <int-e> "that was unheard of even in the AMD optimization guides"
17:36:25 <int-e> ais523: Yeah that's what I had in mind with "FPU extensions"
17:37:54 <int-e> recalling that MMX was basically just an alternative way to use the existing FPU registers. And then they made them wider and wider. And deeper (more registers) too.
17:39:05 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:41:34 <int-e> I wonder what crazy mind thought it would be a good idea to make the FPU registers a (very small) stack...
17:42:41 <int-e> . o O ( job security for compiler writers? )
17:43:30 <ais523> it lets you efficiently write arbitrary expressions that don't use an operand twice and don't overflow the stack
17:43:49 <ais523> the FPU designers may have underestimated the number of expressions that violate one of those restrictions
17:44:11 <ais523> lots of golfing languages are stack-based, so I imagine the same motivation was involved here
17:45:19 <int-e> I've handwritten a tiny amount of x87 FPU code and keeping track of the stack was a hassle because it changes with every instruction... so basically I had a comment on each listing the whole stack contents
17:45:40 -!- littlebobeep has joined.
17:45:59 <int-e> anyway... I'm sure it made sense to somebody but it's still one of the worse design decisions in the x86 space to my mind.
17:46:36 <int-e> I mean, compactness of instructions may have played a role... you could get away with single operand instructions for the most part
17:46:53 <int-e> but was it worth it? I don't think so :P
17:47:28 <ais523> Java bytecode is stack-based, but it uses registers for method arguments
17:47:38 <ais523> (which is weird, most stack/register mixes use the stack for arguments and registers for temporaries)
17:48:10 <ais523> I'm not sure whether register- or stack-based syntaxes are generally better in terms of performance metrics
17:48:40 <int-e> java's bytecode is a bit like x86... it should really be redesigned. but there's too much crap that depends on it so it'll never happen.
17:48:53 <ais523> in golfing languages, tacit syntaxes seem to be winning at the moment, but I suspect they don't scale well, especially when using low-level instructions
17:49:22 <ais523> I'm trying to remember how WebAssembly works, is that entirely register-based?
17:49:25 <FireFly> int-e: and just like x86, it's being replaced by something else (cf dalvik, ART)?
17:50:11 <int-e> FireFly: but what will happen to all the classloaders that "enhance" the bytecode?
17:50:28 <FireFly> is that common in java applications?
17:50:40 <FireFly> I guess I'm blissfully unaware..
17:50:53 <ais523> (I had a previous job working with low-level details of Java, so I've been more exposed to this than most)
17:54:10 <int-e> it has some horrors... like large constant arrays being turned into an initializer that... loads an array, dups, loads an index, loads a value, stores, etc...
17:54:45 <int-e> ...and IIRC chained to another method if that exceeds the maximum size of a method which is 64kb.
17:55:19 <int-e> I've not touched Java in over a decade and I'm happier for it.
17:55:30 <esolangs> [[Uyjhmn n]] https://esolangs.org/w/index.php?diff=98359&oldid=98350 * ChuckEsoteric08 * (+3)
17:56:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
17:56:06 -!- littlebo1eep has joined.
17:56:24 <ais523> most of the things I liked about Java retroactively turned out to be false statements
17:56:26 <int-e> (probably not quite true... I suspect I've written a dozen lines somewhere, or maybe debugged some Java code that came from someone on IRC)
17:56:54 <ais523> in particular, I overestimated how stable it would be – Java programs have a tendency to break over time, and I was hoping they wouldn't
17:57:40 <int-e> I suspect it's fine (though quite complicated when it gets to Java EE stuff) if you're not the type who looks behind the curtain.
17:58:31 <int-e> Oh, sure. That's more of an software engineering lie, isn't it? APIs evolve, causing stuff to break, even in Java.
17:58:59 <int-e> And old versions *will* be discontinued eventually.
17:59:29 <ais523> there are plenty of languages which have managed not to remove any of their old APIs
17:59:53 <ais523> even in C, which has been around for over 40 years since standardisation, I think nothing's been removed other than gets()
18:00:24 <esolangs> [[Uyjhmn n]] https://esolangs.org/w/index.php?diff=98360&oldid=98359 * ChuckEsoteric08 * (+108)
18:04:23 <int-e> and yet, most old C code won't work... for different reasons
18:04:54 -!- tromp has joined.
18:04:58 <int-e> (it's way too easy to rely on undefined behavior in C, and for a long time, compilers just did the obvious thing)
18:05:04 -!- littlebo1eep has quit (Ping timeout: 240 seconds).
18:05:22 <int-e> but I guess that's a digression from the topic
18:06:39 -!- littlebobeep has joined.
18:06:42 <ais523> Perl has incredibly good backwards compatibility in terms of the language itself, although some code has stopped working due to library dependencies outside the language implementation
18:08:27 <Corbin> shachaf, river: I'm thinking about computing that expected value. I'm thinking specifically about ex(n) = log(n) + loglog(n) + logloglog(n) + ...
18:09:23 -!- ais523 has quit (Quit: quit).
18:16:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
18:25:57 -!- littlebobeep has joined.
19:01:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
19:04:19 <esolangs> [[OHE]] https://esolangs.org/w/index.php?diff=98361&oldid=84052 * Kaveh Yousefi * (+281) Added an interpreter implementation in Common Lisp and introduced the category tag Implemented.
19:18:51 -!- Noisytoot_ has joined.
19:19:45 -!- Noisytoot has quit (Ping timeout: 258 seconds).
19:32:54 -!- littlebobeep has joined.
19:35:50 <b_jonas> "Perl has incredibly good backwards compatibility in terms of the language itself," => that's a bit of an exaggeration. it has decent backwards compatbility, but not incredibly good.
19:41:40 -!- Noisytoot_ has changed nick to Noisytoot.
19:45:42 -!- Thedarkb-Desktop has joined.
19:46:11 <b_jonas> `<ais523> although "dec rcx" is only one byte longer than "lock" on x86_64' => no, the former is three bytes and the latter is one byte
19:46:13 <HackEso> <ais523>? No such file or directory
19:51:21 <b_jonas> `<ais523> still has "lock" too, although it's been repurposed as a general-purpose prefix that changes the meaning of an instruction' => not so, that's just about the only prefix that hasn't been repurposed that way. the operand size prefix, the rep and repnz prefix have been repurposed, plus there are new prefixes allocated among the two-byte opcodes starting with 0F byte, but the lock prefix still
19:51:23 <HackEso> <ais523>? No such file or directory
19:51:27 <b_jonas> does only atomic memory locking, though the specific semantics has been refined
19:52:17 -!- littlebobeep has quit (Remote host closed the connection).
19:52:31 <b_jonas> "<int-e> leading to some weirdness around `rep ret` a while ago, I forgot why that was a thing." => that's an alternative to ret to make the jump destination predictor cache happier
19:52:52 -!- littlebobeep has joined.
19:52:55 <b_jonas> ah yes, ais already answered that
19:56:10 <b_jonas> "the FPU designers may have underestimated the number of expressions that violate one of those restrictions" => not really, that's why there are instructions to push a copy of any element on that stack or pop into any element on that stack in 8087
19:56:39 <b_jonas> so if you wish, you can use the stack as one accumulator and seven registers
19:57:05 <b_jonas> or you can use it as a normal stack but use a few elements at the bottom to store constants that you don't pop throughout a loop
19:57:28 <tromp> shachaf: you might like the Levenshtein number encoding
19:58:50 <tromp> which I rediscovered myself, see section 4.5 of https://tromp.github.io/cl/LC.pdf
20:10:58 <b_jonas> anyway, the stack-based design in 8087 probably made slightly sense when it was in a separate coprocessor chip than later when it became a normal part of the CPU in more expensive 486s
20:11:09 <b_jonas> s/slightly sense/slightly more sense/
20:12:49 <shachaf> I never remember which is which with all the names like Levenshtein and Elias omega/delta/whatever.
20:15:31 <zzo38> Can a variant RCA connection be made that can be used with balanced audio in one cable but also is usable as non-balanced audio with existing equipment if one or more of the source/cable/receiver are non-balanced?
20:21:09 <zzo38> (This is one feature I intend for Digi-RGB specification)
20:23:02 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:29:13 -!- tromp has joined.
20:44:43 <esolangs> [[Uyjhmn n]] M https://esolangs.org/w/index.php?diff=98362&oldid=98360 * PythonshellDebugwindow * (+1) /* Computational class */ Fix typo
20:56:55 <Corbin> tromp: Nice diagrams, thanks.
21:18:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
21:21:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:28:49 <esolangs> [[BunnyBell Documentation]] https://esolangs.org/w/index.php?diff=98363&oldid=98358 * PixelatedStarfish * (-272) /* Commands */
21:31:36 -!- definitelya has quit (Quit: h).
21:51:38 -!- tech_exorcist has quit (Quit: Disconnecting).
21:54:08 <Sgeo> I suppose no one would happen to know off the top of their head if NOS2 has a built in hex viewer (or more likely an octal viewer)?
21:57:17 <int-e> . o O ( This is the wrong OS, but: What an od thing to ask. )
22:05:30 -!- littlebobeep has joined.
22:06:58 <Sgeo> That's helpful instead of trying to use a Hex viewer in Windows and using calc to convert to octal when I eventually find the NOS2 octal viewer
22:07:52 <Sgeo> (I'm assuming NOS2 would have an octal viewer maybe but not a hex viewer. It uses 60-bit words, no bytes to be seen)
22:13:18 <Sgeo> Context: The publicly downloadable PLATO distribution has Windows/Mac/linux stuff deep within it. Someone had extracted those and I have access to that, but only because I joined a mailing list. I want to learn how to do that using only publicly available resources. I can use PF to go PLATO -> NOS2 and NOS2 has an XMODEM program, but the end result keeps being corrupt. I want to see what the file looks like resting in NOS2
22:15:29 <Sgeo> Hmm. od doesn't match up with the known good file in HxD or with what I see at the PLATO level (which does match with HxD of the known file)
22:16:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
22:17:39 -!- littlebobeep has joined.
22:22:38 -!- __monty__ has quit (Quit: leaving).
22:25:10 -!- littlebo1eep has joined.
22:27:34 -!- littlebobeep has quit (Ping timeout: 240 seconds).
22:30:04 -!- littlebobeep has joined.
22:33:04 -!- littlebo1eep has quit (Ping timeout: 240 seconds).
22:46:55 -!- littlebo1eep has joined.
22:48:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
23:03:16 <Sgeo> An operating system for the CDC 6600 and related machines, early supercomputers by Control Data Corporation
23:03:50 <Sgeo> PLATO, an educational system that had early multiuser experiences like forums and multiplayer games and chat rooms, ran on it
23:04:06 <Sgeo> https://www.cyber1.org/ https://codex.sjzoppi.com/doku.php?id=utilities:start
23:04:27 <Sgeo> (CYBIS = PLATO)
23:05:01 <b_jonas> Sgeo: ah, so some very old systems
23:05:39 <b_jonas> Sgeo: can you perhaps extract the files or memory dump in a format that you can load in a newer system to hexdump there?
23:06:24 <Sgeo> If I knew how to do that I wouldn't bother trying to figure out the xmodem stuff. Although people on the mailing list have been pointing me to tools to do exactly that >.>
23:07:37 <b_jonas> Sgeo: how much are you working with physical machines versus emulation with modern tools?
23:07:55 <Sgeo> Emulation only.
23:14:11 <b_jonas> ok, that should be slightly easier then
23:38:34 -!- littlebo1eep has quit (Ping timeout: 240 seconds).
23:38:39 -!- relrod has quit (Ping timeout: 240 seconds).
23:40:10 -!- benji has quit (Ping timeout: 240 seconds).
23:40:32 -!- littlebobeep has joined.
23:42:40 <esolangs> [[Talk:OW-1]] https://esolangs.org/w/index.php?diff=98364&oldid=98349 * Potato Imaginator * (+60)
23:42:53 <esolangs> [[Talk:OW-1]] M https://esolangs.org/w/index.php?diff=98365&oldid=98364 * Potato Imaginator * (+84)
23:51:56 -!- benji has joined.
23:52:04 -!- littlebobeep has quit (Ping timeout: 240 seconds).
23:52:59 -!- relrod has joined.
23:56:55 -!- littlebobeep has joined.