←2022-02-18 2022-02-19 2022-02-20→ ↑2022 ↑all
02:10:28 -!- Lykaina has joined.
02:10:39 <Lykaina> hi
02:11:22 <Lykaina> what's a good paste site? i want a peer review of a language i just wrote
02:16:53 <Lykaina> https://pastebin.com/801zLHMr
02:17:33 <Lykaina> it's incomplete, of course
02:27:13 -!- dyeplexer has joined.
02:40:30 <Lykaina> i just want comments on it
02:53:25 <Lykaina> do you want me to discuss it? i haven't even named it
02:58:19 <Corbin> Lykaina: Looks alright. Did you have a use case in mind?
03:00:02 <Lykaina> arduino scripting
03:01:48 <Lykaina> this is the limit of my documentation abilities
03:02:14 <esolangs> [[Teramithic]] https://esolangs.org/w/index.php?diff=93227&oldid=93226 * Digital Hunter * (+5662) /* Examples */ hopefully some kind of implementation of more complex datatypes. Pun somewhat intended
03:03:53 <Lykaina> it currently uses 4 files on the sd card
03:04:12 <Lykaina> i think it only needs to use 2
03:04:46 <Lykaina> i forgot why the interpreter was written to have two 2-byte files on the sd card
03:07:47 <Lykaina> i'll have to rewrite the interpreter
03:37:31 <Lykaina> done
03:38:24 <Lykaina> the 64k storage is on the sdcard, as is the program code
03:40:02 <Lykaina> moved the pointers off the sd card. there was no sane reason for them to be there
03:41:26 <Lykaina> i definitely need to make sure i can load and store a buffer to storage
03:48:04 <Lykaina> there. now i just have to code it.
04:12:05 <Lykaina> done
04:46:59 -!- sgji has joined.
04:50:20 -!- lagash has quit (Quit: ZNC - https://znc.in).
04:55:16 -!- lagash has joined.
05:43:40 <Lykaina> https://pastebin.com/801zLHMr has been updated
06:04:19 -!- immibis has joined.
06:05:39 -!- immibis_ has quit (Ping timeout: 256 seconds).
06:31:09 -!- immibis has quit (Ping timeout: 256 seconds).
08:22:00 -!- definitelya has joined.
09:15:08 -!- dyeplexer has quit (Ping timeout: 272 seconds).
09:29:41 -!- dyeplexer has joined.
09:39:01 -!- immibis has joined.
09:48:36 -!- dyeplexer has quit (Ping timeout: 240 seconds).
10:01:05 -!- dyeplexer has joined.
10:26:36 -!- dyeplexer has quit (Ping timeout: 240 seconds).
10:39:45 -!- dyeplexer has joined.
10:47:17 -!- dyeplexer has quit (Ping timeout: 256 seconds).
10:57:35 -!- Sgeo has quit (Read error: Connection reset by peer).
10:59:35 -!- dyeplexer has joined.
11:22:25 <shachaf> int-e: Hmm, you're not into consensus, but how do you feel about distributed transactions?
11:23:02 <riv> hi Lykaina
11:23:12 <riv> i use debian pastebin https://paste.debian.net/
11:23:39 <riv> the language looks good, like it's an assembly or opcode language
11:33:02 -!- tech_exorcist has joined.
12:39:18 <esolangs> [[Special:Log/newusers]] create * Vic * New user account
12:45:37 -!- dyeplexer has quit (Ping timeout: 240 seconds).
12:45:56 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=93228&oldid=93208 * Vic * (+233) /* Introductions */
12:49:52 <esolangs> [[Brainfuck implementations]] https://esolangs.org/w/index.php?diff=93229&oldid=92989 * Vic * (+223) /* Normal implementations */
13:02:40 <esolangs> [[Fun Craft]] https://esolangs.org/w/index.php?diff=93230&oldid=89288 * ManiPM * (+361)
13:20:13 -!- razetime has joined.
13:43:32 <esolangs> [[Fun Craft]] https://esolangs.org/w/index.php?diff=93231&oldid=93230 * ManiPM * (+413)
13:44:34 <int-e> shachaf: I have two generals still failing to agree on a time to attack
13:44:45 <int-e> shachaf: but I guess transactions are fine as long as you don't commit them
13:44:55 <esolangs> [[Fun Craft]] https://esolangs.org/w/index.php?diff=93232&oldid=93231 * ManiPM * (+4)
13:54:18 -!- dyeplexer has joined.
13:59:16 <b_jonas> Lykaina: https://dpaste.com/ and https://dpaste.org/ (that's two different ones)
14:01:25 <esolangs> [[Fun Craft]] M https://esolangs.org/w/index.php?diff=93233&oldid=93232 * ManiPM * (+5) /* List OF Commands */
14:23:31 <fizzie> I'm using 0x0.st these days.
15:27:47 <esolangs> [[Kak-]] N https://esolangs.org/w/index.php?oldid=93234 * ChuckEsoteric08 * (+342) Created page with "{{Stub}} '''Kak-''' is esolang that minimises [[Kak]]. It has 2 commands. The programm is inside loop. ==Commands== ! - same as [[Kak]] I - skip next instruction if bit is 0..."
15:29:43 <esolangs> [[Kak]] https://esolangs.org/w/index.php?diff=93235&oldid=92636 * ChuckEsoteric08 * (+22)
15:35:47 <esolangs> [[Kak-]] https://esolangs.org/w/index.php?diff=93236&oldid=93234 * ChuckEsoteric08 * (+47)
15:47:30 <esolangs> [[Esolang:Sandbox]] https://esolangs.org/w/index.php?diff=93237&oldid=93215 * AmNow * (+66) useless function woah
15:55:39 <esolangs> [[Special:Log/newusers]] create * Unforswearing * New user account
16:04:46 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=93238&oldid=93228 * Unforswearing * (+257) /* Introductions */
16:07:27 <esolangs> [[Kak--]] N https://esolangs.org/w/index.php?oldid=93239 * ChuckEsoteric08 * (+236) Created page with "{{Stub}} '''Kak--''' or '''USLAK''' ('''Us'''eless '''la'''nguage Ka'''k''') is a language derived from [[Kak-]]. It also uses same loop ==Commands== ! followed by space - sa..."
16:08:22 <esolangs> [[Kak]] https://esolangs.org/w/index.php?diff=93240&oldid=93235 * ChuckEsoteric08 * (+11)
16:21:15 -!- Lykaina has left.
16:41:56 <esolangs> [[Kak]] https://esolangs.org/w/index.php?diff=93241&oldid=93240 * ChuckEsoteric08 * (+256)
16:44:56 <esolangs> [[Kak]] https://esolangs.org/w/index.php?diff=93242&oldid=93241 * ChuckEsoteric08 * (+31)
16:45:13 <esolangs> [[Kak]] https://esolangs.org/w/index.php?diff=93243&oldid=93242 * ChuckEsoteric08 * (+1)
16:52:41 <esolangs> [[User:AmNow]] https://esolangs.org/w/index.php?diff=93244&oldid=90663 * AmNow * (+1)
17:07:02 <esolangs> [[Kak-]] https://esolangs.org/w/index.php?diff=93245&oldid=93236 * ChuckEsoteric08 * (-38)
17:08:44 -!- razetime has quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.).
17:09:07 -!- razetime has joined.
17:13:44 -!- razetime has quit (Client Quit).
17:13:53 <esolangs> [[Kak-]] https://esolangs.org/w/index.php?diff=93246&oldid=93245 * ChuckEsoteric08 * (+136)
17:14:00 -!- razetime has joined.
17:14:10 -!- razetime has quit (Client Quit).
17:14:33 -!- razetime has joined.
17:15:05 -!- razetime has quit (Client Quit).
18:25:01 -!- Eldrax has joined.
18:25:31 -!- Eldrax has quit (Client Quit).
18:28:10 -!- ^[ has quit (Quit: ^[).
18:41:30 -!- dyeplexer has quit (Remote host closed the connection).
18:55:13 <shachaf> int-e: Yes, I was wondering about that sort of thing.
18:55:44 <shachaf> Is it possible for a distributed transaction system to have the property that, when a transaction that writes to shards X and Y is committed, after a client ever sees the X write, their future reads from Y will always see the Y write (and vice versa)? I mean independent reads from X and Y, not transaction reads.
19:10:56 -!- ^[ has joined.
19:19:04 <b_jonas> I was wondering about a different stupid transaction thing
19:19:58 <b_jonas> so you know how there are these data structures that use atomic memory access to make sure you can safely access them simultaneously from multiple threads
19:20:24 <b_jonas> you don't need to lock them because the atomic memory writes make them always appear in a valid state
19:21:04 <b_jonas> and then there are locked data structures that have mutexes or read-write locks inside them so you have to lock part or all of them before you can read or write them safely
19:21:24 -!- Sgeo has joined.
19:22:38 <b_jonas> when you want to represent something that sematically makes sense to access from multiple threads, I think I understand why you can make a representation for them that uses locks. this is always possible because in the worst case you can just put everything behind one global lock, but usually I know how to do better than that.
19:23:45 <b_jonas> the important and non-esoteric question is how to make a lockless representation for everything that could have one. I don't understand this. I know a few simple structures where you can make a lockless representation, but they all seem like a special case rather than something I could generalize even informally.
19:24:42 <b_jonas> anyway, the stupid eso-question is, is there ever a data structure using atomic memory access that is lockless and always appears to be in a valid state when you read it, but needs a lock when you write it so that two threads don't write it in a conflicting way?
19:25:40 <b_jonas> I probably can't answer the eso question because I don't understand the real question
19:30:37 <b_jonas> shachaf: does "future reads" mean that the second client initiates the read of Y after it sees the value of X?
19:31:15 <b_jonas> it's not just that it receives the result of te read of Y after it receives the result of the read of X, right? because that would be too strong
19:35:37 <shachaf> b_jonas: Yes, certainly.
19:37:05 <shachaf> People talk about the (non-transactional) property "linearizability", which means "once you get an acknowledgement of a write, every successful read in your future light cone will see that write".
19:42:58 -!- Lord_of_Life_ has joined.
19:44:12 -!- Lord_of_Life has quit (Ping timeout: 256 seconds).
19:44:13 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:47:25 <esolangs> [[Kak--]] https://esolangs.org/w/index.php?diff=93247&oldid=93239 * ChuckEsoteric08 * (+162)
20:05:13 <esolangs> [[Xjansk]] https://esolangs.org/w/index.php?diff=93248&oldid=93213 * DanielE * (+1)
20:05:26 <esolangs> [[Xjansk]] https://esolangs.org/w/index.php?diff=93249&oldid=93248 * DanielE * (-2) /* Program examples */
20:11:58 <esolangs> [[Xjansk]] https://esolangs.org/w/index.php?diff=93250&oldid=93249 * DanielE * (+354) /* Program examples */
20:12:16 -!- ^[ has quit (Ping timeout: 250 seconds).
20:12:17 <esolangs> [[Xjansk]] https://esolangs.org/w/index.php?diff=93251&oldid=93250 * DanielE * (-1) /* Truth machine */
20:13:05 <esolangs> [[Truth Machine (language)]] https://esolangs.org/w/index.php?diff=93252&oldid=90163 * DanielE * (-40)
20:16:02 <esolangs> [[Truth-machine]] https://esolangs.org/w/index.php?diff=93253&oldid=93176 * DanielE * (+30)
20:20:16 -!- ^[ has joined.
20:24:29 -!- ^[ has quit (Ping timeout: 256 seconds).
20:39:46 -!- imode has quit (Ping timeout: 272 seconds).
20:52:17 -!- tech_exorcist has quit (Remote host closed the connection).
20:52:38 -!- tech_exorcist has joined.
20:58:41 <b_jonas> shachaf: wait a moment...
20:59:08 <b_jonas> shachaf: is that the property that IRC networks satisfy *because* they're topologically a tree, but they wouldn't if they could have loops?
21:01:26 -!- definitelya has quit (Quit: h).
21:02:10 <shachaf> Is it? I don't know how IRC networks work.
21:02:22 <b_jonas> shachaf: as in, client A joins a channel, and when client B (that's already joined to the channel) sees that client A joined, then client B leaves the channel: then every message on the channel will be received by either A or B, nothing falls in the gap between
21:02:38 <b_jonas> imagine A and B as logbots that change guard if you wish
21:03:11 <b_jonas> and they're likely connected to different servers -- the case when they're connected to the same IRC server is trivial
21:03:59 <b_jonas> and all sorts of ordering rules of messages similar to this
21:04:49 <b_jonas> if a loop on the IRC network were allowed, then this could be false, because the message could get to B's server early but A's server late on two different paths
21:07:16 <b_jonas> but IRC is tree shaped, so a message from C first gets to the server D that's in the of the tree where A and B and C meet, and then D sends it to A and B, and D also has to forward the message that A joined from A to B
21:09:46 <b_jonas> if D forwards the message from C to B before it forwards the join message from A, then B will get the message from C before it parts; otherwise D already knows that A joined and will forward the message from D to A
21:12:18 <b_jonas> this property happens to still work if there's a netsplit, but only because it's very simple; if you try to write a more complicated ordering theorem, they tend to only be true if there's no netsplit and servers reconnecting with a different topology in between them
21:13:18 <b_jonas> in any case, hopefully in the future we can have a non-quite-IRC that sends IRC-like messages but allows loops, though it only starts to matter if we have colonies on like two more planets
21:13:48 <b_jonas> and that protocol won't be on TCP, at least not as we understand TCP now
21:14:08 <b_jonas> (the server-server protocol that is; the client-server protocol could still be on TCP)
21:16:20 <b_jonas> but maybe what you're asking about isn't quite the same. for one it concerns four servers, not three.
21:16:29 <b_jonas> I mean four clients, not four servers
21:16:38 <b_jonas> endpoints, leaves
21:20:59 <shachaf> I'm not quite sure what corresponds to "reads" in this context.
21:21:48 <shachaf> And what guarantees you get from IRC, given that it doesn't give you past logs, for instance.
21:22:05 <b_jonas> anyway, I think an unchanging tree topology would imply the property that you're asking for, but perhaps they aren't equivalent
21:22:26 <shachaf> IRC in general doesn't guarantee message ordering looks the same between participants, does it?
21:22:48 <shachaf> Hmm, which property exactly?
21:23:15 -!- oerjan has joined.
21:23:54 <b_jonas> when you have just one IRC server and clients connected to it, then you have a strict ordering: the server reads messages in some order and processes each one immediately, sending its consequences to all clients, before it starts with the next message that it's read.
21:25:53 <b_jonas> when multiple servers are involved, then something similar is true for each server: the server reads messages from (clients connected to it and neighboring servers) in some order, and sends their consequences immediately before processing anything else, but that sending is only to the neighboring servers, before processing the next message; but the neighboring server reading and processing the message
21:25:59 <b_jonas> that the server sends isn't the same event, that can be delayed arbitrarily
21:27:13 <shachaf> If I was making a distributed chat thing, I'd probably really want strong consistency guarantees, and use a consensus/atomic broadcast sort of thing.
21:27:51 <b_jonas> the magic, which I don't understand, is how servers reconcile conflicting commands, like conflicting mode changes
21:28:33 <b_jonas> I believe that if everyone stops sending messages about a channel then all the servers within a connected component will eventually agree on the channel being in the same state, as in same modes and ban lists and channel op lists and list of users joined,
21:28:38 <b_jonas> but how they do this is unclear to me
21:31:35 <b_jonas> also I believe that when someone sends a PRIVMSG on a channel, then only the server closest to it checks the channel permissions for whether they can send that message i.e. that they're joined on the channel and (not banned and not quieted on the channel and (channel mode -m or they have voice) or channel mode +z)) or channel has -n mode (only it's more complicated because more modes and features
21:31:41 <b_jonas> interact into this)
21:35:30 <b_jonas> also WHOIS with one argument is a local command (i.e. your server will reply you without having to wait for any other server), but WHOIS with two arguments is a remote command (your server will send a request to other servers, go on with their life including process other messages from you and send you other replies, and later reply you when it receives a reply from another server, it sends you a reply
21:35:36 <b_jonas> to that WHOIS)
21:36:51 <b_jonas> this is what I gathered back when I asked questions about IRC on freenode/#freenode
21:37:39 <b_jonas> and obviously they only have authority about what freenode does, because someone else could run an IRC network that kind of pretends to be IRC but doesn't satisfy its invariants
21:42:17 <fizzie> I kind of imagine Twitch chat's internal server-to-server protocol is all unrelated.
22:16:14 <b_jonas> fizzie: yes, twitch is unrelated, it just gives a kind-of IRC-like interface towards clients, but it cares less and less to pretend that it's IRC
22:29:27 -!- ^[ has joined.
22:58:00 -!- tech_exorcist has quit (Quit: Disconnecting).
←2022-02-18 2022-02-19 2022-02-20→ ↑2022 ↑all