01:03:48 <esolangs> [[User:Masalt]] https://esolangs.org/w/index.php?diff=105259&oldid=105252 * Masalt * (+4)
01:30:17 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105260&oldid=105213 * Dtp09 * (+1) /* greater, less, equal, jump, rand */
01:50:55 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105261&oldid=105260 * Dtp09 * (-85) /* Comments */
01:52:19 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105262&oldid=105261 * Dtp09 * (-2) /* Opcodes */
01:52:43 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105263&oldid=105262 * Dtp09 * (-58) /* Opcodes */
01:53:30 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105264&oldid=105263 * Dtp09 * (+58) /* Opcodes */
01:54:50 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105265&oldid=105264 * Dtp09 * (+67) /* Opcodes */
01:59:28 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105266&oldid=105265 * Dtp09 * (+209) /* Opcodes */
01:59:29 <esolangs> [[EsoFur]] N https://esolangs.org/w/index.php?oldid=105267 * TaserTheFox * (+2484) Created page with "'''EsoFur''' is a joke programming language created by [[User:TaserTheFox]], partially inspired by [[FurASM]] == Commands == {| class="wikitable plainpres" |+ Commands |- ! Command !! What It Does |- | OwO What's This? || Start Of Program |- | QwQ || End Of Program |
02:04:39 <esolangs> [[EsoFur]] M https://esolangs.org/w/index.php?diff=105268&oldid=105267 * TaserTheFox * (+91)
02:07:04 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=105269&oldid=105187 * TaserTheFox * (+13) /* E */ new language
02:08:44 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105270&oldid=105266 * Dtp09 * (+2) /* Opcodes */
02:13:52 <esolangs> [[User:TaserTheFox]] M https://esolangs.org/w/index.php?diff=105271&oldid=105240 * TaserTheFox * (-24)
02:19:19 <esolangs> [[User:TaserTheFox]] M https://esolangs.org/w/index.php?diff=105272&oldid=105271 * TaserTheFox * (+25)
02:30:31 -!- razetime has joined.
02:40:32 -!- razetime has quit (Remote host closed the connection).
02:55:08 -!- ^[ has quit (Ping timeout: 252 seconds).
02:59:35 -!- chiselfuse has quit (Ping timeout: 255 seconds).
03:01:43 -!- chiselfuse has joined.
03:06:37 <esolangs> [[Number-code]] https://esolangs.org/w/index.php?diff=105273&oldid=100166 * Username * (+59) /* Syntax */
03:10:52 <esolangs> [[Number-code]] https://esolangs.org/w/index.php?diff=105274&oldid=105273 * Username * (+31) /* Syntax */
03:17:35 <esolangs> [[Number-code]] https://esolangs.org/w/index.php?diff=105275&oldid=105274 * Username * (+120)
03:18:22 <esolangs> [[Number-code]] M https://esolangs.org/w/index.php?diff=105276&oldid=105275 * Username * (+3) /* Examples */
03:38:38 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105277&oldid=105270 * Dtp09 * (-233) /* Replacements */
04:21:24 -!- ^[ has joined.
04:34:23 -!- razetime has joined.
04:34:47 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105278&oldid=105277 * Dtp09 * (+83) /* Replacements */
04:35:08 <esolangs> [[Ababab]] N https://esolangs.org/w/index.php?oldid=105279 * Username * (+0) Created blank page
04:43:09 <esolangs> [[Joke language list]] https://esolangs.org/w/index.php?diff=105280&oldid=104846 * TaserTheFox * (+13) /* General languages */
04:44:28 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105281&oldid=105278 * Dtp09 * (+12) /* Starting a program */
04:45:04 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105282&oldid=105281 * Dtp09 * (+42) /* Starting a program */
05:02:39 <esolangs> [[Truth-machine]] https://esolangs.org/w/index.php?diff=105283&oldid=105087 * TaserTheFox * (+204)
05:09:14 -!- chiselfuse has quit (Remote host closed the connection).
05:09:30 -!- chiselfuse has joined.
05:10:10 -!- SGautam has joined.
05:10:53 -!- tromp has joined.
05:11:35 -!- tromp has quit (Client Quit).
05:20:18 -!- chiselfuse has quit (Read error: Connection reset by peer).
05:20:41 -!- chiselfuse has joined.
05:35:36 <esolangs> [[Tile/Textile]] https://esolangs.org/w/index.php?diff=105284&oldid=105282 * Dtp09 * (-10) /* Starting a program */
06:09:42 <int-e> Hmm, slow AoC day... seems I'm not the only one who struggled with parsing the specification. (The twist is less exciting, but I guess it'll stump quite a few people anyway.)
06:16:21 -!- chiselfuse has quit (Remote host closed the connection).
06:16:34 -!- chiselfuse has joined.
06:31:23 <HackEso> ‘Life,’ said Marvin, ‘don't talk to me about life.’
06:53:27 -!- tromp has joined.
07:03:19 <Sgeo> Someone made a Subleq based game
07:03:22 <Sgeo> https://www.reddit.com/r/programminggames/comments/zi889t/sic1_a_singleinstruction_subleq_programming_game/
07:32:15 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
07:51:00 -!- tromp has joined.
07:51:11 <int-e> (but I think I'll stop after the first two level sets)
08:02:21 <int-e> Though hmm. I wonder how long it'll take to get to self-modifying code.
08:03:14 <int-e> But the 3rd set isn't going there yet.
08:16:42 <int-e> Ah. It's set number 4.
08:19:28 -!- SGautam has quit (Quit: Connection closed for inactivity).
08:24:55 -!- b_jonas has quit (Ping timeout: 260 seconds).
09:11:49 -!- Sgeo has quit (Read error: Connection reset by peer).
09:11:53 -!- Sgeo_ has joined.
09:14:04 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
10:10:58 <Sgeo_> Ooh optimization hints
10:17:34 -!- Lord_of_Life_ has joined.
10:18:04 -!- Lord_of_Life has quit (Ping timeout: 268 seconds).
10:18:49 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
10:32:21 -!- Sgeo_ has quit (Read error: Connection reset by peer).
10:32:26 -!- tromp has joined.
11:01:02 -!- V has quit (Read error: Connection reset by peer).
11:02:19 -!- V has joined.
11:26:44 -!- chiselfuse has quit (Ping timeout: 255 seconds).
11:28:59 -!- chiselfuse has joined.
11:30:00 -!- chiselfuse has quit (Read error: Connection reset by peer).
11:34:22 -!- chiselfuse has joined.
11:41:35 -!- chiselfuse has quit (Ping timeout: 255 seconds).
11:42:56 -!- chiselfuse has joined.
11:53:34 -!- bgs has joined.
14:24:11 <fizzie> Successfully predicted the AoC twist.
14:24:30 <fizzie> But it did take a while to find the "divided by three" bit in that wall of text.
14:25:12 <int-e> I didn't think about what the twist would be.
14:25:25 <int-e> (While doing part 1)
14:26:14 <fizzie> I just inadvertently guessed from the fact that the tests in the input were the first 8 primes.
14:26:22 <fizzie> Not that it's an inevitable consequence of that, but still.
14:26:47 <int-e> And even with that twist, it didn't really push the limits of it.
14:26:58 <int-e> You could've done this with a hundred monkeys.
14:27:56 <fizzie> According to https://zem.fi/tmp/aoc/twist.html people either found it less twisty than previous days, or else the timing is biased from the fact that understanding the description (and writing the boilerplate to parse the input) probably made part 1 take longer.
14:28:17 <int-e> (gur qvssrerapr jbhyq or gung lbh'q jbex zbqhyb rnpu cevzr vaqvivqhnyyl, gnpxvat n erznvaqre cre zbaxrl, engure guna hfvat gur ypz bs nyy gur zbqhyv)
14:28:58 <fizzie> In terms of https://zem.fi/tmp/aoc/stats.aligned.ratio.html it does have approximately the same fraction of "only solved part 1" people than day 9.
14:32:00 <fizzie> Did I mention I tried to make ChatGPT do ROT-13 assignments by starting the prompt by explaining to it what ROT-13 was? It replied by explaining back what ROT-13 is, and then answering something that looked like an entirely random question. Like, I asked it for "what's six multiplied by seven?" (which it can do in plaintext) and it replied by telling me the capital of France.
14:33:34 <int-e> Well, it does seem to have a slight edge on day 9.
14:38:29 <esolangs> [[Quudo]] https://esolangs.org/w/index.php?diff=105285&oldid=104910 * SwitchU42 * (+59)
14:39:59 <esolangs> [[Quudo]] https://esolangs.org/w/index.php?diff=105286&oldid=105285 * SwitchU42 * (+48)
14:48:47 -!- ^[ has quit (Ping timeout: 252 seconds).
15:01:11 -!- ^[ has joined.
15:07:41 -!- chiselfuse has quit (Ping timeout: 255 seconds).
15:08:01 -!- chiselfuse has joined.
15:21:09 <esolangs> [[Quudo]] https://esolangs.org/w/index.php?diff=105287&oldid=105286 * SwitchU42 * (+99)
15:37:26 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:23:22 -!- tromp has joined.
16:28:25 -!- SGautam has joined.
16:39:46 -!- b_jonas has joined.
16:56:35 -!- chiselfuse has quit (Ping timeout: 255 seconds).
16:58:28 -!- chiselfuse has joined.
17:04:39 <int-e> fizzie: Oh another silly thing that AoC could've done for a harder twist is ask for something big like 10^12 steps with a small-ish number of monkeys. This is feasible because the items are independent, and the number of states per item stays manageable.
17:05:32 <int-e> Probably too early for that... and perhaps it has too much of a Project Euler flavor.
17:17:27 <esolangs> [[Quudo]] https://esolangs.org/w/index.php?diff=105288&oldid=105287 * SwitchU42 * (+94)
17:21:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:33:02 <esolangs> [[Quudo]] https://esolangs.org/w/index.php?diff=105289&oldid=105288 * SwitchU42 * (-9)
17:41:58 -!- razetime has quit (Remote host closed the connection).
17:57:57 <esolangs> [[Special:Log/newusers]] create * VBerstis * New user account
18:11:25 -!- tromp has joined.
18:14:22 <esolangs> [[Esolang:Introduce yourself]] M https://esolangs.org/w/index.php?diff=105290&oldid=105238 * VBerstis * (+244) /* Introductions */
18:19:42 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=105291&oldid=105269 * VBerstis * (+28) /* S */
18:23:17 <zzo38> What customizable mahjong games, including Japanese rules, are suitable for Linux, with FOSS and without 3D graphics?
18:32:29 <esolangs> [[SNOBOL5]] N https://esolangs.org/w/index.php?oldid=105292 * VBerstis * (+686) Created page with "SNOBOL5 is an update from SNOBOL4. More information can be found at http://snobol5.org . Oregon SNOBOL5 is an open source implementation for 64bit Windows and Linux on x86 processors. SNOBOL originated in Bell Laboratories in the 1960's. The language is useful for
18:37:37 -!- SGautam has quit (Quit: Connection closed for inactivity).
18:42:43 <esolangs> [[Fractran]] M https://esolangs.org/w/index.php?diff=105293&oldid=71078 * VBerstis * (+157)
18:49:14 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:01:57 -!- tromp has joined.
19:38:03 -!- cakeprophet has joined.
19:40:42 <fizzie> Meh. Day 11 wasn't exactly pleasant in Burlesque. Also, the part 2 solution takes 59 seconds for the example and 124 seconds for my puzzle input. :/
19:41:42 <cakeprophet> I don't think there's anything inherently wrong with Unicode string types, but they are often poorly designed or poorly used. For example, libraries using Unicode strings as inputs when they actually want bytestring inputs, and vice versa. It can be a problem for example when a library wants to "support Unicode" so they use the Unicode type, but
19:41:42 <cakeprophet> what they actually wanted was to be encoding-agnostic which means they should have used a bytestring instead. Really you should only be using a Unicode string when your code needs to perform Unicode-specific operations on Unicode code points.
19:41:55 <cakeprophet> and when languages prioritize them over raw bytestrings, like when string literals are always UTF-8 encoded strings and using bytestrings requires extra code to convert to raw, developers will typically take the path of least resistance and use Unicode strings everywhere when they don't really need to
19:42:46 <cakeprophet> the types themselves can be poorly designed or have inconsistent/unexpected semantics. In Javascript, writing a C-style for loop over a string will index the bytes of the string, while using an iterator will iterate over the codepoints instead. "string.length" will return the raw bytes and the only way to get the number of codepoints is to iterate
19:43:22 <cakeprophet> a JS string literal "Hello" is always a UTF-16 encoded string. To use a raw string you need to convert to Buffer with Buffer.from(string). This leads to UTF-16 strings showing up in libraries where they don't belong
19:44:23 <cakeprophet> I would guess what made the switch from Python 2 to 3 so slow and painful for the Python community was the fact that it switched to an "everything is Unicode" design but for real-world Python apps doing real-world things everything is not, in fact, Unicode.
19:44:32 <zzo38> cakeprophet: Yes, those are actually what my concerns were. The presence of a Unicode string type tends to cause libraries to use them when they should not do so. I also think that there is nothing inherently wrong with a Unicode string type if you do not have to use it and string functions are available for byte strings too, but they do tend to be poorly designed and poorly used.
19:45:08 <cakeprophet> huge networking libraries like Twisted had to totally rewrite all of their string code to convert to/from bytestrings and the standard library utilities that were available in Python 2 for formatting/converting bytestrings were just flat out missing in Python 3. And, on top of all this, they needed to maintain compatibility with the old Python 2
19:45:28 <zzo38> In other words, I agree with your points.
19:45:37 <cakeprophet> the design assumption for Python 3 was "everything should just be using Unicode anyway" but that only makes sense in the context of user-facing applications that display human-readable text to users. Networking code often doesn't and shouldn't use Unicode
19:48:16 <zzo38> However, I think that "everything should just be using Unicode anyway" is wrong even in the context of user-facing applications that display human-readable text to users, but whether or not that is the case still has the other problems that you and I mentioned.
19:49:08 <cakeprophet> it's technically wrong, yes. but from practically correct in 2022
19:53:55 <cakeprophet> but yes if raw byte strings are a widely supported language primitive it's a non-issue because any encoding is easy to support then
19:56:21 -!- earend1 has quit (Quit: Connection closed for inactivity).
20:00:53 <cakeprophet> it's more about "does the application need to be aware of human-language factors". An IRC client for example displays human-readable text to users and is user-facing, but doesn't really care too much about the message encoding itself. So when creating a Haskell IRC bot I would use ByteString at the transport level but would convert to Text for
20:00:53 <cakeprophet> commands if I needed to manipulate the text in some way (parse and split on Unicode spaces of different types to split into words, uppercase and lowercase, etc)
20:01:35 <esolangs> [[FlipJump]] M https://esolangs.org/w/index.php?diff=105294&oldid=102091 * Tomhe * (-136)
20:01:36 <cakeprophet> the IRC protocol spec doesn't say anything about the message encoding other than the protocol commands are all basic ASCII
20:07:27 <cakeprophet> often for user apps the answer is "yes it does need to be aware of that" and the most commonly used encodings are Unicode encodings. so that's why I say for "user-facing apps" it often makes sense, though it's not always the case
20:08:50 <cakeprophet> but yeah, I think if you took the unicode changes out of Python 3 the entire Python codebase probably would have migrated from 2 to 3 within a year or two at most.
20:10:25 <cakeprophet> instead it took like, what, 10 years? to confidently say "most Python code is Python 3"
20:13:45 -!- Sgeo has joined.
20:47:03 <esolangs> [[User:XKCD Random Number]] https://esolangs.org/w/index.php?diff=105295&oldid=103786 * MathigonDec * (+46) Newline eliminated
20:51:48 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:54:28 -!- tromp has joined.
20:58:43 <esolangs> [[BrainDestructionByCode I]] N https://esolangs.org/w/index.php?oldid=105296 * Threesodas * (+1659) Created page with "'''BrainDestructionByCode I''' is an esoteric language designed to drive the programmer insane, created by [[User:Threesodas|threesodas]]. = Cells of BDBCI = BDBCI is a cell based programming language, similar to [[brainfuck]]. It has a finite amount
21:08:59 <esolangs> [[EsoFur]] https://esolangs.org/w/index.php?diff=105297&oldid=105268 * TaserTheFox * (+1052) added error list
21:09:20 <esolangs> [[EsoFur]] M https://esolangs.org/w/index.php?diff=105298&oldid=105297 * TaserTheFox * (+0)
21:25:43 <JAA> cakeprophet: Fortunately, IRCv3 introduced UTF8ONLY to signal to clients that data must be UTF-8. If you send something invalid to those servers with that enabled, you get an error (or even a disconnect) or the message gets modified to be valid.
21:36:30 <zzo38> I think it is a bad idea (as are many other parts of IRCv3, but not all of them), and it would be better to somehow declare the character encoding on a channel (or user, in the case of private messages). However, when bridging to other services, sometimes being restricted to a specific character encoding (or even further restricted) may be necessary. (Usually this would be UTF-8, but not always.)
21:40:29 <zzo38> Many of my own programs do not, and probably will not, ever support Unicode. (I mostly program in C, though, rather than Python)
21:50:22 <zzo38> Possibly, can also be written ICNU which can be alternative of ICU, but does not need to be converted to/from Unicode and can deal with any encoding (including Unicode).
22:06:43 -!- bgs has quit (Remote host closed the connection).
22:12:46 <esolangs> [[SNOBOL5]] M https://esolangs.org/w/index.php?diff=105299&oldid=105292 * PythonshellDebugwindow * (+58) Stub, categories
22:28:12 <cakeprophet> JAA: hmm yeah that's too simplistic of an approach. but I guess it makes it easy to implement for existing IRC code. a way to declare expected encodings at server, channel, and message level would be best I think. UTF-8 is most efficient for English text but UCS-2 or UTF-16 would be a more efficient choice for Chinese characters.
22:29:05 <cakeprophet> I don't think there's anything wrong with no enforcing an encoding in the IRC spec. it's a good thing in the sense that it doesn't limit encoding choices for servers/clients. But there should just be an easy way to declare what encoding is being used as metadata
22:31:10 <JAA> I think it makes far more sense to standardise on one encoding that can cover (pretty much) all glyphs out there than the minor efficiency gain from using a more specific encoding.
22:31:45 <JAA> Overcomplication is nice in esolangs but not so much in serious code. :-)
22:37:39 <JAA> There's an argument for other encodings due to the hard line length limit, and IRCv3's been working on that with the multiline spec (sadly still WIP though).
22:37:53 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:38:54 <cakeprophet> I don't think it's overly complicated it's just as complicated as encodings themselves are. It's equivalent complexity to <meta charset="utf-8"> and it's not like these are unused encodings with no library support practically everything supports these encodings. message and channel level encoding could be overkill but at a minimum having a
22:38:54 <cakeprophet> server-level encoding metadata isn't overcomplication. if an IRC server is primarily for Chinese languages then it doesn't make sense to use UTF-8 when UCS-2 and UTF-16 is widely used. hell even legacy chinese encodings can still be commonly found in China
22:41:04 <JAA> Yeah, true for UTF-16 and probably UCS-2, but then people will immediately ask for JIS, GBK, EUC, and whatnot. That way lies madness.
22:42:31 <JAA> It still makes a relatively simple protocol significantly more complicated for a very minor advantage in very specific circumstances. That's overcomplication to me.
22:43:57 <JAA> Same reason why almost everyone uses UTF-8 for web pages these days, even if sometimes another encoding could be marginally more efficient. And IRC uses even less bandwidth than HTML over HTTP.
22:44:27 <cakeprophet> sure, why not support those. I understand the appeal of strongarming everything into UTF-8 but there's a reason we have multiple Unicode encodings and not just one. Back in the old days of "encoding hell" I think everyone thought the solution was to just have one encoding to rule them all, but really what would be best is a consistent encoding
22:44:28 <cakeprophet> standards, metadata support for multiple encodings at protocol/file type level, and universal library support for all common encodings
22:45:38 <cakeprophet> UTF-8 is good enough for most purposes so it's an appealing and easy solution to just say "everything is UTF-8 now" but I think there are motivations for other encodings in the right contexts. Maybe not IRC specifically but in general.
22:47:13 <cakeprophet> efficiency concerns are a non-issue in the context of IRC generally. but the line limitation issue is a good example where UTF-8 is not ideal in all cases
22:48:28 <JAA> Yeah, I think I agree with that. We're way further from a consistent encoding metadata standard than a universal encoding though. I doubt the former will ever happen, to be honest.
22:49:22 <cakeprophet> depends. I think on Web encoding support is fairly solid. but honestly since much of what I encounter is UTF-8 anyway it's hard for me to quantify encoding support across devices and browsers
22:50:01 <JAA> Sure, I meant as a true universal standard that can be applied to 'anything', not just HTML.
22:50:51 <JAA> Say 'utf-8:some text encoded as UTF-8' or whatever, and that would work whether it's in a chat message, on a web page, or in a text file.
22:51:23 <cakeprophet> which is kind of the problem with everyone adopting a universal encoding. when it DOES make more sense to use the "ideal" encoding, often the support is not given because "everyone should just be using UTF-8 anyway". I see a problem with this mindset even though, for practical purposes, it currently works most of the time.
22:53:34 <cakeprophet> yeah there's no way to universally support that it has to be done in every standard and every protocol design. which requires devs to be a bit more thoughtful than just "oh everyone is using UTF-8 anyway who cares"
22:55:20 <zzo38> I think that there is no "ideal" character set (not just encoding) for all uses. This depends on not only what language you are writing but also how the data is to be used.
22:58:38 <zzo38> The fact that many modern programs insist on Unicode causes some problems, including that displaying Chinese and Japanese text correctly can be difficulty, that xterm will fail to display some characters from some DEC character sets (either correctly, or at all, sometimes), that the way text directions and other things are handled will cause problems in some cases, and character widths (sometimes ambiguous), etc.
23:00:25 <zzo38> They keep changing the character encoding of the rules of Magic: the Gathering, but fortunately it isn't difficult to find out what encoding it uses (and then I just convert all of them to ASCII).
23:05:27 <zzo38> For naming character encodings, I had considered to use an extension of the IBM code page numbers; numbers higher than 65535 can be used for encodings that do not have a IBM code page number. Many of them have no Unicode mapping (although some do, and this mapping is not necessarily different than the mapping of other code pages even if the code pages are different).
23:10:53 <zzo38> For example, you will not want to be limited to Unicode and can use TRON code, and others.
23:23:43 -!- earend1 has joined.
23:28:59 <zzo38> Unfortunately, most fonts are made for Unicode and many libraries are designed for Unicode fonts, making it difficult to use non-Unicode, but I must try to write such thing anyways.
23:59:12 -!- cakeprophet has quit (Quit: Client closed).