←2019-03-21 2019-03-22 2019-03-23→ ↑2019 ↑all
00:00:21 -!- tromp has joined.
00:17:26 <oerjan> @metar ENVA
00:17:28 <lambdabot> ENVA 212350Z 18011KT CAVOK 01/M04 Q1024 RMK WIND 670FT 21018KT
00:21:35 <shachaf> `` doag | grep '> #' | awk '{print $2}'
00:21:38 <HackEso> ​<oerjän> \ <oerjän> \ <oerjän> \ <oerjän> \ <oerjän> \ <coppr̈o>
00:24:14 <oerjan> `doag src/hello3.c
00:24:16 <HackEso> 11756:2019-03-21 <oerjän> # Preserve fizzie\'s repaired version//`mk src/hello3.c//const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\\x0f\\x05XX\\xc3";
00:24:46 <oerjan> `` doag | grep '> #' | grep copp
00:24:48 <HackEso> 1181:2012-12-18 <coppr̈o> addquote < zzo38> What is portable way of load/save floating points in files, using a C code? < kmc> #ifndef __STDC_IEC_559__ #error Here\'s a nickel, kid. Buy a real computer. #endif
00:24:57 <oerjan> aha
00:25:13 <oerjan> i don't think coppro has used that nick since i added `#
00:29:20 -!- Lord_of_Life_ has joined.
00:31:52 -!- Lord_of_Life has quit (Ping timeout: 250 seconds).
00:31:54 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
00:33:36 <kmc> hehe I'm happy with that quote
00:33:42 <kmc> it stands the test of time
00:42:38 -!- tromp has quit (Remote host closed the connection).
00:46:51 <fizzie> `sled src/hello3.c//s/x0f/17/;s/x05/5/;s/xc3/303/
00:46:53 <HackEso> src/hello3.c//const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\17\5XX\303";
01:34:06 <oerjan> fizzie: i advertized that on PPCG's chat
01:34:22 <oerjan> (s?)
01:34:32 <oerjan> s.
01:34:43 <moony> i just found a known working MC88110 for sale.
01:34:46 <moony> yes
01:34:51 * moony celebrate
01:36:50 <oerjan> ^celebrate
01:36:50 <fungot> \o| c.c \o/ ಠ_ಠ \m/ \m/ \o_ c.c _o/ \m/ \m/ ಠ_ಠ \o/ c.c |o/
01:37:33 <oerjan> not the same since the monqy exodus.
01:38:25 <oerjan> `? monqy
01:38:26 <HackEso> monqy is no longer extant. He lives in concept, hidden, unfindable. You could ask itidus21 for details, if you find him.
01:38:42 <oerjan> hm i think i may be confusing people
01:38:56 <oerjan> `grwp feet
01:38:58 <HackEso> limerick:A limerick is a verse with two left metrical feet and three right metrical feet. \ myndzi:myndzi used to keep us all on our feet.
01:39:05 <oerjan> myndzi it was.
01:39:20 <fizzie> oerjan: I've been working on a "proper" printable version, in the something that fits in the same 'const char main[]' form but uses only valid UTF-8 printable Unicode characters (to make 'ret' available).
01:39:27 <fizzie> But since it can't use syscall (0f 05 is just not okay), it's a lot more complicated. I have a non-printable version now for looking up "puts" and "exit" via ELF auxiliary vector -> program header -> PT_DYNAMIC section -> DT_DEBUG entry -> struct link_map list of linked libs -> string/symbol tables of all loaded libraries.
01:39:36 <fizzie> It's already 214 bytes without any work to make it printable.
01:40:09 <kmc> is it cheating to use the dynamic linker?
01:40:15 <kmc> because you could look for a PLT entry
01:40:18 <zestymug> yes
01:40:21 <kmc> mm
01:40:28 <zestymug> I think it is
01:40:29 <kmc> there's also a syscall instruction in the VDSO isn't there
01:40:37 <fizzie> kmc: Not in x86-64 any more.
01:40:44 <kmc> or... you could just scan all of +x memory for 0f 05
01:40:48 <fizzie> kmc: Or, I mean, yes, there's three syscall instructions, but not one just for calling.
01:40:58 <kmc> fizzie: but you can jump to any point can't you
01:41:02 <j4cbo> you’ve read the tom7 printable compiler paper right?
01:41:04 <kmc> i guess it might be hard to get control back
01:41:06 <kmc> oh yes
01:41:15 <kmc> tom7 is a mad genius
01:41:19 <fizzie> kmc: Yes, but there's usually annoying code after, and in any case it doesn't feel right relying on those sort of offsets.
01:41:28 <kmc> fizzie: well, fair enough
01:41:33 <fizzie> Scanning memory for the right thing would presumably work though.
01:42:48 <oerjan> . o O ( until the compilers start putting in traps to prevent it )
01:43:28 <fizzie> Also, I gave some thought about using the int 0x80 syscall interface, because "int 0x80" is printable (U+0340 COMBINING GRAVE TONE MARK), but the problem with that is that there's no mappings below the 2G limit, and that thing's "write" can only push through 32 bits of pointers.
01:43:29 <oerjan> or kernels, whatever
01:44:04 <fizzie> And the mmap syscall on x86-32 takes the arguments packed into a struct, so you'd need a pointer in order to get some memory you can point at.
01:47:02 <kmc> can't you use the stack for that, though?
01:47:29 <fizzie> No, because the stack is somewhere around 0x7ffe70532000.
01:48:01 <fizzie> So a pointer to something on it would get truncated.
01:48:27 <fizzie> I mean, it's very arbitrary that I'm trying to make this a x86-64 binary. If I just compiled it with -m32, it'd be simple.
01:49:14 <kmc> ah yeah
01:49:38 <kmc> and you're not allowed to define any symbols but 'main', right?
01:49:59 <fizzie> Well, it's not like there's a law. But that's what I've been operating under.
02:32:43 -!- zestymug has quit (Ping timeout: 256 seconds).
02:36:58 -!- FreeFull has quit.
02:37:13 <esowiki> [[Special:Log/newusers]] create * W3Rn1ckz * New user account
02:40:06 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=60556&oldid=60540 * W3Rn1ckz * (+258) /* Introductions */
03:14:52 <esowiki> [[Functasy]] M https://esolangs.org/w/index.php?diff=60557&oldid=60552 * Hakerh400 * (-43) /* Advanced examples */
03:37:48 -!- izabera has changed nick to redbutt.
03:54:04 -!- danieljabailey has joined.
03:56:19 -!- redbutt has changed nick to izabera.
04:31:33 -!- ^[ has quit (Ping timeout: 250 seconds).
04:32:07 -!- ProofTechnique has quit (Ping timeout: 240 seconds).
04:33:08 -!- dingwat has quit (Ping timeout: 268 seconds).
04:34:25 -!- ProofTechnique has joined.
04:34:25 -!- ^[ has joined.
04:36:06 -!- dingwat has joined.
04:47:38 -!- oerjan has quit (Quit: Nite).
04:51:47 -!- tromp has joined.
04:56:39 -!- tromp has quit (Ping timeout: 268 seconds).
05:56:32 -!- danieljabailey has quit (Ping timeout: 244 seconds).
06:40:07 -!- tromp has joined.
06:44:23 -!- tromp has quit (Ping timeout: 252 seconds).
07:47:48 <b_jonas> "<fizzie> If I just compiled it with -m32, it'd be simple." => no, it wouldn't be, because HackEso doesn't have the necessary system headers installed so you can't easily compile to x86_32 with gcc with the default options
08:02:31 -!- tromp has joined.
08:15:24 <b_jonas> "And the mmap syscall on x86-32 takes the arguments packed into a struct" => are you sure? because it only has six arguments, and the linux man-pages don't mention that. can you use the ipc system call to map a sysvipc shared memory segment instead?
08:17:37 <b_jonas> I think it's the socket syscalls that take argument the way you describe: http://man7.org/linux/man-pages/man2/socketcall.2.html
08:21:06 <b_jonas> fizzie: and http://man7.org/linux/man-pages/man2/syscall.2.html confirms that syscalls take up to six arguments on x86_32
08:21:17 <b_jonas> with the int80 interface
08:23:25 <b_jonas> http://man7.org/linux/man-pages/man2/mmap.2.html and http://man7.org/linux/man-pages/man2/mmap2.2.html describe the specific syscall
09:03:56 -!- b_jonas has quit (Quit: leaving).
09:05:34 -!- tromp has quit (Remote host closed the connection).
09:30:05 -!- arseniiv has joined.
09:36:45 -!- nfd9001 has quit (Read error: Connection reset by peer).
09:38:14 -!- nfd9001 has joined.
09:38:19 -!- tromp has joined.
09:57:55 -!- danieljabailey has joined.
10:09:58 -!- ais523 has joined.
10:13:00 <fizzie> @tell b_jonas No, the man pages describe the C wrappers. See https://github.com/torvalds/linux/blob/master/mm/mmap.c#L1624
10:13:00 <lambdabot> Consider it noted.
10:13:06 <fizzie> @tell b_jonas However, it seems like only the "legacy" mmap call uses the struct wrapper, and the more modern mmap_pgoff (the one that takes page offset and is behind mmap2) is defined via SYSCALL_DEFINE6, so should in fact be callable: https://github.com/torvalds/linux/blob/master/mm/mmap.c#L1616
10:13:07 <lambdabot> Consider it noted.
10:13:16 <fizzie> @tell b_jonas I know you can pass 6 arguments via the in 0x80 interface, I don't know why the old_mmap call packs them in a struct. Maybe the interface was slightly different in olden times.
10:13:16 <lambdabot> Consider it noted.
10:15:54 -!- AnotherTest has joined.
10:43:47 <ais523> I vaguely remember that an old, old syscall interface took fewer arguments than that
10:55:37 <int-e> naturally; x86 simply had fewer registers to spare
10:59:36 -!- dingwat has quit (Ping timeout: 252 seconds).
11:01:01 -!- dingwat has joined.
11:34:48 <int-e> Well, or so I thought. They're using all 7 of them now, even ebp, which I expected to be left out.
11:49:17 <ais523> oh wow, why did I never see ELVM before? https://github.com/shinh/elvm
11:49:21 <ais523> somehow I am not surprised at the author
11:49:51 <ais523> (it's a C compiler modified to support a range of esolangs as backends, e.g. it can compile to BF, INTERCAL or Whitespace)
11:51:01 <ais523> also, sizeof(char) == sizeof(int) == sizeof(void*), and CHAR_BIT varies but is usually 24 :-D
11:55:11 <int-e> ais523: did you see the reference that I added to https://esolangs.org/wiki/Talk:Interfrac ? (I was almost giddy when I finally found it. It's actually a different source than I originally had for ILP in NP.)
11:55:36 <int-e> (And I still don't know where that was.)
11:55:38 <ais523> no, but I've seen it now
12:07:12 -!- mich181189_ has joined.
12:09:05 -!- S_Gautam has joined.
12:14:34 -!- Cale has quit (*.net *.split).
12:14:34 -!- mich181189 has quit (*.net *.split).
12:14:37 -!- mich181189_ has changed nick to mich181189.
12:17:34 -!- HackEso has quit (Ping timeout: 255 seconds).
12:17:41 -!- HackEso has joined.
12:20:48 -!- Cale has joined.
12:27:31 -!- wob_jonas has joined.
12:28:05 <wob_jonas> fizzie: was that old_mmap syscall even used on x86_32?
12:28:46 <wob_jonas> I'll try to look this up later
12:29:39 <wob_jonas> wati
12:29:45 <wob_jonas> there's a note about mmap in http://man7.org/linux/man-pages/man2/syscalls.2.html
12:30:53 <wob_jonas> fizzie: sorry, you're right. that note tells that because the original mmap is a very old syscall, it used to be called with a parameter block on x86_32, despite that six arguments can be passed in syscalls in x86_32 now
12:32:26 <wob_jonas> fizzie: ok, so you can call the mmap2 system call, or the ipc system call in the shmget mode, to get a memory mapping.
12:32:39 -!- Lord_of_Life_ has joined.
12:33:20 -!- Lord_of_Life has quit (Ping timeout: 244 seconds).
12:35:03 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
12:45:44 -!- danieljabailey has quit (Ping timeout: 272 seconds).
13:11:17 <wob_jonas> ais523: yes, you're right, apparently there is a historical artifact there in the original mmap syscall.
14:03:45 <int-e> shachaf: ftr, you're an evil person ;-) (I relented and bought Baba is You and I've already sunk 11 hours into it)
14:05:21 <wob_jonas> int-e: how many levels does that have? I hope they improved level design since that demo
14:06:24 <int-e> more than a hundred
14:07:00 <int-e> and at least one level is impossible (probably not really but I have no clue how it's supposed to work)
14:29:00 <wob_jonas> int-e: I see
14:33:49 <ais523> suppose you're writing an esolang which does I/O as individual bits; should bits within a byte be big- or little-endian?
14:34:04 <ais523> unlike bytes within a word, for which there are several good reasons to be little-endian, I can't see a reason to break the symmetry here
14:34:50 <int-e> I guess I'd prefer big endian for human readability: 00100000 for a space
14:35:53 <int-e> I guess big endian is slightly easier for input, little endian slightly easier for output? At least when doing the standard multiplication/division based base conversions.
14:36:01 <ais523> I'm wondering whether one particular endianness might be easier to produce from within esolang code
14:36:20 <ais523> hmm, yes, you save a temporary in both cases, don't you?
14:36:48 <ais523> although not really, because you need a loop counter anyway, and you can use the same temporary for the loop counter and for remembering which bit you've reached
14:36:51 <wob_jonas> ais523: yeah, that's the sort of thing I have to decide for specifying (and implementing) a standard library for consumer society, although it's not necessarily base 2, I can use larger bases (3 or 4 or 5 or 8 or 16), and not only for IO, but for arithmetic too
14:38:13 <wob_jonas> so far I think I'll be using the endianness where the code emits the higher order bits first
14:38:14 <ais523> also you can shift the bits into the number backwards, if you have 256/128 as a constant or wrapping storage
14:38:18 <ais523> in BF it's often easier to read the top bit of a number than the bottom bit…
14:38:21 <ais523> or, hmm, now I'm not sure; the top bit (for some fixed bitwidth) is easier to read in a non-wrappinig impl, but you can read the bottom bit in a wrapping impl by multiplying by 128 and checking to see whether you have 0
14:38:32 -!- ais523 has quit (Quit: sorry for my connection).
14:38:44 -!- ais523 has joined.
14:46:40 <wob_jonas> I think you can read the lowest bit in brainfuck too.
14:48:10 <ais523> well, BF is transformation-on-memory-complete, the question is as to how easy the various bit-reading codes are
14:48:45 <ais523> this problem comes up in The Waterfall Model too, I haven't decided whether it's easier to read high bits or low bits first
14:49:03 <wob_jonas> this should read the low bit: >[-]+>[-]>[-]<<< [- >[->>+<<]>[-<+>]>[-<+>]<<<]
14:49:07 <ais523> (you either repeatedly halve, or else compare against something that's repeatedly halving)
14:49:26 <wob_jonas> clears the three fields to the right, then puts the parity to the field two to the right while zeroing the current cell
14:49:41 <wob_jonas> you could also copy the value if you don't want to destroy it
14:49:53 <int-e> ais523: in a typical language I'd do the equivalent of acc = 0; for (i = 0; i < 8; i++) { acc = 2*acc + get_bit(); }
14:50:09 <ais523> well, 128 in a wrapping impl can be obtained via --[>-<--]>-
14:50:32 <ais523> you can change the >-< to a nondestructive add to get a nondestructive multiply-by-128
14:50:32 <wob_jonas> ais523: how do you read the seventh bit?
14:50:43 <ais523> that's got to be shorter, but you'd then have to double the number to read the next bit
14:50:53 <int-e> rather than acc = 0; bit = 1; for (i = 0; i < 8; i++) { if (get_bit()) { acc += bit }; bit *= 2; }
14:51:17 <int-e> (this is assuming something without builtin bit shift (or exponentiation))
14:51:55 <ais523> acc = 0; for (i = 1; i != 256; i*=2) { if (get_bit()) acc += i; }
14:52:02 <int-e> ... I misplaced that semicolon in "};".
14:52:15 <ais523> I think that's less natural than your first example, but it's way shorter than the second
14:52:32 <int-e> if I can compare wit 256 easily... sure.
14:52:44 <ais523> well, in wrapping BF it's very easy, comparing with 256 is what ] does :-)
14:53:09 <int-e> . o O ( let's take a 16 bit variant )
14:53:15 <int-e> ;)
14:53:32 <ais523> then the same code reads a 16-bit character and you don't have to change it at all :-)
14:53:48 <int-e> Also input may be less important than output? Or not? It really depends on what you want to do...
14:54:18 <int-e> ...and the difference between big endian and little will always be relatively insignificant, I think.
14:55:20 <ais523> what got me thinking about this was "suppose you're making an IR to target esolangs, what does I/O look like?"
14:55:40 <ais523> unary is an option and has several advantages, but also a clear disadvantage
14:58:31 -!- arseniiv has left ("gone too far").
14:58:43 -!- arseniiv has joined.
15:01:10 <ais523> I think the optimum is probably unary for text output (likely with 1 = NUL, 2 = SOH, etc., and 0 = EOF); and binary for binary output
15:01:24 <ais523> (in either case the language itself would just output 0s and 1s, just the interpretation of them would be different)
15:03:41 <wob_jonas> ais523: I'm definitely not going to use unary. I'm going to use radixes between 2 and 16 inclusive.
15:04:31 <ais523> wob_jonas: well, we're designing different languages, so your usecase may well be different from mine
15:04:47 <ais523> I guess this goes back to the whole "what is a number?" question
15:05:10 <wob_jonas> sure
15:05:20 <ais523> and in esolangs, at least, the answers seems fairly clear for nonnegative integers: it's a count of something, typically data or loop iterations
15:05:58 <wob_jonas> part of the reason why I want a radix higher than 2 for some options is to make the code more compact, so that if I want to put an integer literal in the source code, I don't have to enter 32 bits, but instead just 8 hexits
15:05:58 <ais523> so "do this 4 times" is a property inherent in the number 4, it's what defines it, really (because it lets you impose 4ness onto arbitrary structures)
15:06:07 <ais523> and "output a 1 bit 4 times" is how you output the numebr 4 in unary
15:06:26 <ais523> wob_jonas: isn't that just syntax, though? you could have the lexer expand your high-radix number into unary
15:06:29 <ais523> (+)*12345
15:07:38 <wob_jonas> ais523: the syntax itself doesn't know about numbers. only the standard library knows about them, and the standard library interface is such that I can implement the arithmetic library in pure Consumer Society. in fact that's how I want to implement it first, just to prove that it works, and then I add an optimized implementation into the interpret
15:07:38 <wob_jonas> er.
15:08:07 <wob_jonas> the library can't add arbitrary syntax to the language
15:08:14 <ais523> OK, and you don't want a preprocessor
15:08:51 <wob_jonas> yes, or at least, I have a specific syntax in mind, and want to make that work
15:09:36 <wob_jonas> the reference implementation would then store the numbers as binary internally
15:09:44 <wob_jonas> but that isn't visible in the interface
15:10:05 <ais523> well, IMO a good Underload interpreter should store numbers in binary
15:10:12 <ais523> internally
15:10:15 <ais523> but the syntax doesn't work like that at all
15:10:43 <wob_jonas> why not? if you want to handle large numbers in underload, you can implement a binary representation in underload just fine
15:11:12 <wob_jonas> in this case I want to handle 32-bit numbers because I decided I want to implement the SGB random generator, and that uses 32-bit division
15:11:43 <wob_jonas> and then I'll implement a maze generator that calls that random number generator
15:12:03 <ais523> wob_jonas: because the binary representation is very inconvenient for working with
15:12:10 <ais523> you wouldn't be able to multiply with just *, for example
15:12:14 <wob_jonas> so some numbers will be greater than 2**30, but I won't repeat anything as many times
15:12:44 <ais523> make the interpreter use bignums internally
15:12:51 <wob_jonas> ais523: yes, I'll have to implement the multiplication and division myself. I've implemented binary arithmetic a fwe times already, so I know what I'm getting myself into
15:13:01 <ais523> all esolang interpreters should do that unless the esolang inherently has a word size cap (which IMO is bad esolang design)
15:13:11 <wob_jonas> ais523: for underload, yes, I'd use bignums. for Consumer society, that's not so easy
15:13:56 <ais523> from my point of view, the best way to write esolangs is normally for the program to handle numbers in unary (simplest), and the interpreter to optimize that, unless the esolang is timing-dependent in some way and thus can't be optimized
15:14:42 <wob_jonas> it's not that 32 bits is an inherent limit. I could implement 128 bits instead if I wanted to, for just slightly larger code, but if I do 32 bits, that makes it clear enough that I could do larger if I wanted while keeping the code clean.
15:18:22 <ais523> it'd be hard to imagine an esolang where 32 bits /is/ an inherent limit (so, of course, I'm trying)
15:26:10 <wob_jonas> ais523: I don't think it would be hard. x86_32 already has built-in 32-bit integers, and you can encourage that even more if you don't expose a carry flag and don't expose high multiplication.
15:27:04 <wob_jonas> yeah, and don't expose double shift and don't expose unsigned division either. it goes a long way to make longer arithmetic inconvenient, but still totally realistic and characteristic of real cpus.
15:27:24 <wob_jonas> sure, that means it's for non-esoteric languages, but I don't see why an esoteric language couldn't do the same
15:27:44 <wob_jonas> intercal already has 16 bits as an inherent limit, and I can imagine a 32-bit variant.
15:56:27 <ais523> the 16 is arbitrary though
16:08:03 <esowiki> [[Livefish]] N https://esolangs.org/w/index.php?oldid=60558 * Areallycoolusername * (+1681) Created page with "[[Livefish]] is an [[esoteric programming language]] made by [[User: Areallycoolusername|Areallycoolusername]]. It's the opposite of [[Deadfish]] in that it has a way to input..."
16:10:55 <esowiki> [[Joke language list]] https://esolangs.org/w/index.php?diff=60559&oldid=60547 * Areallycoolusername * (+71) /* General languages */
16:17:12 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
16:18:30 <ais523> Livefish would be /way/ more interesting if i was input, and o was some other operation
16:18:39 <ais523> that said, it would still likely be uninteresting
16:19:11 <esowiki> [[Livefish]] https://esolangs.org/w/index.php?diff=60560&oldid=60558 * Areallycoolusername * (+131)
16:19:18 <ais523> you can write practically useful TC input-only languages, though (e.g. context-free grammars); they provide observable output in the form of halt/nonhalt
16:19:32 <esowiki> [[Livefish]] https://esolangs.org/w/index.php?diff=60561&oldid=60560 * Areallycoolusername * (-31)
16:20:41 <esowiki> [[Livefish]] https://esolangs.org/w/index.php?diff=60562&oldid=60561 * Areallycoolusername * (+6)
16:22:08 <esowiki> [[Livefish]] https://esolangs.org/w/index.php?diff=60563&oldid=60562 * Areallycoolusername * (+10)
16:22:42 <esowiki> [[Livefish]] https://esolangs.org/w/index.php?diff=60564&oldid=60563 * Areallycoolusername * (-17) /* Categories */
16:51:54 <shachaf> int-e: Which level is impossible?
16:53:00 <int-e> Level 12 in the forest... skull house. I don't want any spoilers though.
16:54:05 <shachaf> Of course.
17:05:55 <esowiki> [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60565&oldid=59883 * Areallycoolusername * (+249)
17:07:07 <esowiki> [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60566&oldid=60565 * Areallycoolusername * (+34)
17:07:19 <esowiki> [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60567&oldid=60566 * Areallycoolusername * (+2)
17:48:45 -!- S_Gautam has quit (Quit: Connection closed for inactivity).
17:51:21 -!- danieljabailey has joined.
17:55:49 -!- adu has joined.
18:16:01 <fizzie> Huh. I somehow thought when you call int 0x80 in a 64-bit binary, you go through the compatibility layer where the syscall numbers are the x86-32 ones, and you pass in 32-bit ebx/ecx/edx/etc registers. In actual fact, it looks like when I call int 0x80 it's interpreted using the 64-bit syscall numbers and register order. Or at least that's how strace is printing them.
18:16:21 <fizzie> Maybe strace is just confused by the whole concept. Because the call doesn't actually do anything, and it prints "?" as the return value too.
18:19:38 <fizzie> Right, I think that's just strace. Because when I try to run the regular "syscall"-based version with int 0x80, strace prints write(1, "Hello world!\n", 13) = ? but the process just exits. (The 64-bit syscall write number 1 is exit on the i386 side.)
18:20:17 -!- b_jonas has joined.
18:20:31 <fizzie> I guess I just won't use strace; just wanted to use it to validate the args. Still getting a -1 (EPERM) out of the purported mmap call.
18:22:56 <fizzie> Oh, looks like it might actually care about fd needing to be -1 when MAP_ANONYMOUS is set. The man page was ambivalent (stating it should be ignored), so I left it at 0 as that was easier.
18:24:36 <fizzie> Or not. I'm getting EBADF when I try to set it to -1.
18:26:09 -!- FreeFull has joined.
18:48:57 -!- danieljabailey has quit (Read error: Connection reset by peer).
18:50:57 <b_jonas> "you can write practically useful TC input-only languages, though (e.g. context-free grammars)" => huh what? no context free grammar is Turing-complete
18:51:05 <b_jonas> ais523: ^
18:51:37 <ais523> I meant context-sensitive grammars
18:51:48 <ais523> and said the wrong thing out of habit because CFGs are common and CSGs are rare
18:52:20 <b_jonas> fizzie: try to call write first, that has the same syscall number in all versions, right?
18:52:46 <fizzie> b_jonas: No, that's what confusing me right before you joined.
18:53:10 <fizzie> b_jonas: The 32-bit write (1) is actually the 64-bit exit, so strace printed "write(...) = ?" + "program exited".
18:53:33 <b_jonas> fizzie: what I don't know is, when you call a syscall with int 80, what registers or register halves is the syscall allowed to clobber
18:53:44 <b_jonas> for the proper x86_64 syscall interface, I do know the answer
18:53:59 <b_jonas> but not for the int 80
18:54:00 <fizzie> Er, I mean, the 64-bit write (1) is the 32-bit exit, is what I needed to say.
18:54:09 <b_jonas> wait what?
18:54:12 <b_jonas> even that's changed?
18:54:13 <b_jonas> wow
18:54:18 <fizzie> Single-stepping with gdb confirms that it exits immediately on the "int 0x80" where eax/rax is 1, so it's being treated in the 32-bit manner, even though strace prints it it as write.
18:55:25 <b_jonas> fizzie: even without strace or gdb, you could get a few bits result out if you make the program (1) call an illegal instruction, (2) cause a segmentation fault by writing to the null page, (3) livelock with an infinite loop
18:55:28 <fizzie> Yes, the syscall_64.tbl list starts at 0 with "read, write, open, close, ..." while the syscall_32.tbl starts from 1 (well, 0 is restart_syscall, that's special) with "exit, fork, ...".
18:56:04 -!- adu has quit (Quit: adu).
18:56:26 -!- adu has joined.
18:56:34 <b_jonas> the 32-bit one starts with exit, fork, read, write, open, close, waitpid, creat, link, unlink, execve, chdir, time, mknod, chmod, lchown, break
18:56:51 -!- adu has quit (Client Quit).
18:56:51 <b_jonas> hmm
18:57:11 -!- adu has joined.
18:57:38 -!- adu has quit (Client Quit).
18:57:39 <b_jonas> that could get ugly the other way, if you try to call write, but actually call fork
18:58:05 -!- adu has joined.
18:58:16 <fizzie> In any case, I'm a bit unsure about this EBADF. I think it's likely using the x86-32 argument registers, because when I change the fifth register (edi) from 0 to -1, the return value goes from -1 (EPERM) to -9 (EBADF).
18:58:17 <b_jonas> and what does the sysenter interface do? is that the same as the int80 interface?
18:58:25 -!- adu has quit (Client Quit).
18:58:28 <fizzie> ...uh, actually, scratch all that. It's just that I can't count.
18:58:47 <fizzie> Turns out 0x20 | 0x40 *isn't* actually 0x40, but 0x60 instead.
18:58:48 -!- adu has joined.
18:58:57 <fizzie> Who knew.
18:59:11 -!- adu has quit (Client Quit).
18:59:22 <fizzie> Well, then it all makes sense, it doesn't have 0x20 (MAP_ANONYMOUS) set so it's either trying to mmap stdin (EPERM) or -1 (EBADF).
18:59:44 -!- adu has joined.
18:59:53 <b_jonas> yeah, it ought to use the x86_32 register conventions if you use int80
18:59:58 -!- adu has quit (Client Quit).
19:00:27 <b_jonas> so the syscall number goes in eax, and the arguments to ebx, ecx, edx, esi, edi, ebp
19:00:44 <ais523> EPERM seems like an interesting error for mmapping stdin
19:01:13 <ais523> it should be EACCES according to the docs
19:01:31 <ais523> oh, but EACCES is "Permission denied"
19:01:37 <ais523> (EPERM is "Operation not permitted")
19:02:04 <fizzie> EPERM The prot argument asks for PROT_EXEC but the mapped area belongs to a file on a filesystem that was mounted no-exec.
19:02:10 <fizzie> It kind of might be an instance of that sort of thing.
19:02:21 <fizzie> I was trying to map it rwx just because there's no reason not to.
19:02:32 <ais523> oh, I see
19:02:41 <ais523> I normally avoid +x in maps
19:02:52 <b_jonas> ais523: yeah, what fizzie says, plus /dev/pts is mounted noexec
19:02:53 <ais523> besides, mapping /anything/ rwx is a huge w^x violation
19:02:58 <fizzie> I thought I might want to run some code in there, though right now it doesn't.
19:03:16 <fizzie> Anyway, with the flags fixed (MAP_PRIVATE | MAP_ANONYMOUS | MAP_32BIT), it's now returning a pointer in the low 32 bits, so that should be fine: http://ix.io/1Ee2
19:03:24 <b_jonas> ais523: like I said yesterday, rwx used to be normal, because for a pretty long time, x86 didn't have a way to mark pages (as opposed to segments) readable but not executable
19:04:03 <ais523> b_jonas: clearly you should just make your mutable variables write-only, then
19:04:29 <ais523> (this is… possibly viable given the right sort of language?)
19:04:40 <b_jonas> ais523: old x86 didn't allow marking a page executable but not readable either
19:05:01 <ais523> now I'm wondering what operations x86 allows on write-only memory, can you do RMW instructions if they don't have visible side effects? I'm guessing no
19:05:48 -!- sebbu3 has joined.
19:06:10 <b_jonas> the whole non-executable page thing came about only because of security people trying to reduce effects of bugs
19:06:49 <b_jonas> wtf was these loud noise
19:09:26 -!- sebbu has quit (Ping timeout: 250 seconds).
19:12:30 <fizzie> Aw. Works locally, crashes on HackEso. That might be a little annoying to debug.
19:12:46 <b_jonas> fizzie: ouch
19:12:54 <b_jonas> fizzie: how do you even compile it on HackEso?
19:13:03 <b_jonas> oh wait
19:13:10 <fizzie> `` echo 'const char main[] = "%0000%HELOP[P]P_4~PY4yPZ4eP^,b,@̀PYSX5Hell1ADSX5o wo1AHSX5rld!1ALSX4@4J1AP4@4GPZ$AP[QX4DPYRX$D̀ß";' | gcc -x c - -o /tmp/hello4 && /tmp/hello4
19:13:11 <b_jonas> you're compiling a x86_64 program, sorry
19:13:11 <HackEso> ​/hackenv/bin/`: line 5: 64 Segmentation fault /tmp/hello4
19:13:14 <b_jonas> that you can compile
19:13:41 <b_jonas> try cheating by making the program not of that format
19:13:59 <fizzie> That command line prints "Hello world!" on both my home machine and this work computer.
19:14:25 <fizzie> Yeah, will have to look into it a bit later, need to go grocery shopping.
19:14:36 <fizzie> But I know the format in general works.
19:15:02 <fizzie> `` echo 'const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\17\5XX\303";' | gcc -x c - -o /tmp/hello4 && /tmp/hello4
19:15:04 <HackEso> Hello world!
19:16:43 <fizzie> The int 0x80 version also works on the machine HackEso is running on, so it's something about the UML sandbox. Which isn't *that* surprising: UML in general does weird things about memory.
19:16:55 <fizzie> Actually, it's a separate Linux kernel.
19:17:05 <fizzie> Maybe it's compiled without the 32-bit emulation in the first place.
19:18:01 <b_jonas> hmm
19:18:20 <kmc> it sure does
19:22:52 <fizzie> I do have that working version that doesn't use any syscalls at all, I just suspect if I finish converting it to be printable in a naive way, it's going to end up being longer than comfortably fits on an IRC line.
19:24:12 <b_jonas> ``` set -e; >tmp/a.c echo $'#include<stdio.h>\n''int main(void) { printf("hello ifrzMgePz7Lg,\n"); }'; gcc -g -Wall -O -fdiagnostics-color=never -o tmp/a.out tmp/a.c; tmp/a.out
19:24:14 <HackEso> hello ifrzMgePz7Lg,
19:24:46 <b_jonas> does it have to fit in an irc line? you can just use multiple irc lines
19:24:59 <fizzie> I guess it doesn't, really, just would be more elegant if it did.
19:25:10 <fizzie> If the word "elegant" can really be attached to that.
19:25:22 <b_jonas> fizzie: it's really the -fdiagnostics-color=never why I don't want to insist on putting all the compilation stuff in one irc line
19:25:51 <b_jonas> it's just a ridiculously long compilation option, and the gcc defaults and libc defaults are somewhat bad for historical reasons,
19:26:20 <b_jonas> so you can end up needing stuff like -std=gnu++-17 and #define _GNU_SOURCE and twenty includes just to do nothing
19:26:35 <b_jonas> and I don't want to omit those just to golf the program
19:27:16 <fizzie> The non-syscall code walks up the stack to reach the ELF auxiliary vector, picks up the AT_PHDR pointer to locate the program header, scans that to find the PT_DYNAMIC section, looks up the DT_DEBUG entry used for communicating between the dynamic linker and a debugger, uses the link_map chain there to enumerate all loaded shared objects, scans through their symbol tables to find "exit" and "puts", and
19:27:22 <fizzie> finally uses those to do the job.
19:27:37 <b_jonas> fizzie: ok, wait a moment
19:27:51 <b_jonas> I think I read something relevant yesterday, let me look it up
19:28:02 <b_jonas> hmm wait
19:28:06 <b_jonas> that was for x86_32 code
19:28:21 <b_jonas> so that can't work
19:29:06 <b_jonas> but still, even in x86_64, there must be a function with a syscall instruction mapped somewhere, that the kernel and libc together use for signal handler magic
19:29:12 -!- tromp has quit (Remote host closed the connection).
19:29:41 <fizzie> Yes, I could definitely do it much easier if I were willing to make it work on one specific libc.
19:29:55 <fizzie> (Or scan through memory to find suitable bytes.)
19:30:12 <fizzie> (Well, maybe that wouldn't be so much easier than the enumerate-symbols approach.)
19:30:56 <fizzie> There's also an easy-to-find entry to locate the vDSO page, which could be used to make a version that reliably works on one specific kernel.
19:31:54 <fizzie> On x86-32 systems, the vDSO actually has a function just for this, __kernel_vsyscall, which is there so that userspace apps can just call that instead of having to do the work of deciding whether sysenter is supported.
19:32:34 <fizzie> On x86-64, that's not there, the page contains just __vdso_clock_gettime, __vdso_getcpu, __vdso_gettimeofday and __vsdo_time.
19:33:04 <fizzie> Some of those do have syscall instructions that could be jumped to, but again that would make the solution brittle if the vDSO contents change.
19:33:06 -!- sebbu3 has changed nick to sebbu.
19:39:01 <b_jonas> fizzie: but doesn't it have to work that way on any libc? I mean
19:39:14 <b_jonas> fizzie: what does the kernel put on the stack when it calls a signal handler?
19:39:29 <ais523> fizzie: I vaguely remember Web of Lies scanning the vDSO to find a syscall instruction
19:39:32 <b_jonas> doesn't it put a return address to a routine that calls the magic system call that tells the kernel that the signal handler has finished?
19:39:37 <b_jonas> wasn't there something like that?
19:39:39 <ais523> and then jumping to it via IP teleportation over ptrace
19:39:50 <b_jonas> maybe I'm confused
19:39:52 <ais523> (it seemed saner than trying to alter the executable's memory image to do a system call)
19:39:53 <b_jonas> I'll have to test that
19:43:21 <fizzie> I think there's a specific system call (sigreturn?) somewhere in user-space code that signal handlers return to, which then informs the kernel that the signal handling is done. But I'm not sure how that helps for this.
19:43:40 <fizzie> Unless there's an easier way to find that code than there is to find the puts/exit functions.
19:44:21 <ais523> syscall/signal interaction is interesting
19:44:37 <ais523> the kernel frequently, either virtually or actually, rewinds the IP a couple of bytes to send it over the same syscall again
19:44:44 <ais523> that's how restartable syscalls are restarted, for example
19:45:00 <ais523> it wouldn't surprise me if sigreturn is used as a replacement syscall for nonrestartable signals in much the same way
19:45:26 <ais523> (fwiw, this mechanism makes it highly likely that syscalls use only caller-saves registers, as it'd be hard to get the parameters correct otherwise)
19:46:51 <b_jonas> ais523: is that really what the kernel does? I always thought it was the libc that handled all the restarting, by intercepting all the sigaction calls to know which signals it has to restart after, and restarting on a -EITNR in the C functions that call the system call
19:47:07 <ais523> b_jonas: no, it happens in the kernel, you can see this using strace
19:47:27 <ais523> there are a few really out-there signal numbers (not in the normal sequence) reserved for this purpose
19:47:31 <b_jonas> and I think the sigreturn had some other reason to exist, not the syscall restarting
19:47:34 <ais523> I can't remember whether they're negative or really large
19:48:16 <b_jonas> but I didn't pay much attention to the whole system call restarting thing, because why would you want that? the whole point of signal handlers is that they must be able to wake up your program, and you can only do that if the system call isn't restarted
19:48:36 <b_jonas> in blocking high level functions like fread, sure, there you restart
19:49:02 <ais523> b_jonas: well, if you've set the signal to SIG_IGN, you presumably don't want the signal to interrupt the system call
19:49:10 <ais523> sometimes that's implemented as restarting it
19:49:13 <b_jonas> but otherwise, when a signal interrupts a syscall, it will be the blocking syscall that is the center of your event loop, like poll or something
19:49:33 <b_jonas> I do understand that the restarting must be handled for compatibility with existing programs of course
19:50:17 <b_jonas> ais523: no! if you set it to SIG_IGN, then the system call isn't interrupted at all, from the user process's point of view. the kernel doesn't have to restart anything, or even interrupt the system call, because it doesn't have to invoke a handler
19:50:39 <ais523> I vaguely remember that the kernel actually /does/ interrupt the system call while it checks to see if there's a handler
19:51:35 <b_jonas> and SIG_IGN has some special semantics for the kernel anyway, it's not just like calling an empty handler: SIG_IGN is inherited through an execve, SIG_IGN on SIGCLD makes the kernel wait all your children when they die.
19:52:33 <ais523> well, what actually matters is the SA_RESTART flag on the signal handler, which can be set independently per-handler (although it defaults to off unless you're using SIG_IGN, IIRC)
19:52:36 <b_jonas> that is why you have to be very careful with SIG_IGN: if a child accidentally inherits it, you can get really hard to debug bugs
19:53:03 <b_jonas> there was a particularly nasty bug in linux distros where some process set sigprocmask and children inherited it, the same could happen with signaction SIG_IGN
19:54:02 <ais523> well, there are some programs that do this sort of thing intentionally
19:54:04 <ais523> nohup comes to mind
19:54:18 <b_jonas> ais523: yeah, I guess what you're saying makes sense, because libc can't easily tell which signal interrupted the syscall
19:57:50 <b_jonas> oh, I know why!
19:58:55 <b_jonas> ais523: the kernel must put something on the stack because on signal return the stack pointer must be modified. on x86_32 that's only if a sigaltstack is active, but on x86_64 always, because there's a redzone
19:59:27 <ais523> oh right, you can't clobber the redzone
19:59:27 <b_jonas> you can't just have the signal handler return like a normal C function, the stack pointer would be wrong
19:59:58 <ais523> what even is the purpose of that thing, anyway?
20:00:58 <ais523> is it just to save a few assignments to SP? or is there some better optimization you can do with it?
20:01:23 <b_jonas> ais523: uh, some optimization thing, but I'm not sure what right now
20:03:12 -!- tromp has joined.
20:03:21 <b_jonas> ais523: I think part of that is that the one-byte displacement you use in x86 addressing modes is a signed int8
20:03:48 <b_jonas> but I think there's something other than that, possibly connected to instructions like push/pop
20:04:32 <ais523> the redzone is 128 bytes, isn't it? that would make a lot of sense if it's the signed-int8 displcement that's relevant
20:07:04 <b_jonas> ais523: something close to that, yes
20:11:20 <b_jonas> ais523: it also allows you to load a value from the stack with pop but still keep the copy on the stack
20:12:10 <ais523> well, the copy isn't on the stack any more, it's in the redzone, but I know what you mean
20:12:13 <b_jonas> I'm not saying this comes up often, but the redzone doesn't have much of a price either
20:13:06 <b_jonas> if the kernel calls a signal handler, those 128 bytes don't cost much even when you aren't using them
20:13:08 <int-e> b_jonas: there's also the bit that tail functions don't have to set up their own stack frame if they need fewer than 120 or so bytes.
20:14:44 <b_jonas> int-e: that could be true even if the redzone was over *rsp, not under, if the calling convention just said that the 120 bytes over the return addess are callee-clobbered
20:15:58 <b_jonas> int-e: basically you have a choice of a constant offset of where the rsp points, and it only matters for when the stack is accessed with small displacements or call/ret/push/pop or similar which use a fixed displacement
20:16:07 <int-e> b_jonas: then you'd pay 120 bytes of stack space for every level of function calls even if no stack frame is allocated at all
20:16:17 <int-e> (just for the return address)
20:16:35 <int-e> hmm
20:16:39 <b_jonas> oh, because it would intersect the previous ret address?
20:16:45 <b_jonas> yeah, sorry, you're right
20:16:49 <b_jonas> that wouldn't work
20:17:08 <int-e> Err, yes, I think what I said is correct. I'm confusing myself.
20:18:14 <b_jonas> int-e: yes, what you say is correct. because the call/ret instructions access right above *rsp, you want space below that that can be used even if you did a dense series of calls and pushed above *rsp
20:19:16 <b_jonas> so the stuff you access with call/ret/push/pop and kin are above the stack pointer, and some of the thing you access only with displacements, not with those instructions, can be above
20:19:20 <b_jonas> some of them can be below
20:19:37 <b_jonas> or perhaps
20:21:19 <b_jonas> well, there definitely has to be a boundary somewhere on the stack so that above that is generally preserved by the callee, below that can be clobbered
20:22:53 <b_jonas> and because of how call/ret/push/pop works, it makes sense to put that boundary near *rsp
20:23:28 <b_jonas> which is why there's a scratch area below [rsp]
20:25:51 <b_jonas> well, I don't really claim I understand this
20:26:02 <b_jonas> figuring out good general-purpose calling conventions is a very hard problem
20:26:08 <b_jonas> good thing we already have one to use
20:28:33 <ais523> it's probably only good on x86
20:28:39 <b_jonas> well sure
20:28:43 <ais523> and any goodness it has is relative to the general insanity of x86
20:28:49 <b_jonas> this is cpu-dependent
20:28:57 <b_jonas> and this is on x86_64 in particular
20:45:15 <b_jonas> ah, the linux manpage http://man7.org/linux/man-pages/man2/sigreturn.2.html gives some info
20:46:20 <b_jonas> ah yes!
20:46:48 <b_jonas> besides setting the stack pointer, it resets the saved sigprocmask. I knew there was something I missed
20:54:42 <b_jonas> hmm
20:55:29 <b_jonas> that won't help, because you need at least either a system call or a symbol lookup to find that function that the signal handler stack frame calls,
20:55:54 <b_jonas> and if can you do a system call or symbol lookup then you no longer need that
20:56:32 <b_jonas> no wait
20:56:32 <b_jonas> wait
20:57:07 <b_jonas> it's a bit non-portable because it technically depends on the kernel version, but you can find the address from just the auxiliary vector I think
20:58:47 <b_jonas> oh
20:58:50 <b_jonas> it might be even better
20:58:53 <b_jonas> I'll have to test this
20:59:13 <b_jonas> hmm no
20:59:15 <b_jonas> darn
20:59:29 <b_jonas> I dunno
21:02:29 <b_jonas> nope
21:02:41 <b_jonas> you need a symbol lookup into libc I think
21:02:46 <b_jonas> so it won't help
21:16:22 <esowiki> [[User:Hakerh400]] https://esolangs.org/w/index.php?diff=60568&oldid=60554 * Hakerh400 * (-188) /* Programming languages we created */
21:16:34 <esowiki> [[Truth-machine]] https://esolangs.org/w/index.php?diff=60569&oldid=60486 * Illuminatu * (+177) /* Implementations */
21:18:43 <esowiki> [[Aeolbonn]] https://esolangs.org/w/index.php?diff=60570&oldid=20079 * Illuminatu * (+97) /* Examples */
21:28:31 -!- arseniiv_ has joined.
21:31:44 -!- ais523 has quit (Quit: quit).
21:32:05 -!- arseniiv has quit (Ping timeout: 252 seconds).
21:33:23 <kmc> smh. arduino is doing some terrible thing where code inside comments gets preprocessor-expanded and then has compiler-level syntax errors
21:33:32 <kmc> I should once again ditch it and write basic AVR C
21:33:40 <kmc> but it's so convenient to throw things together
21:33:43 <kmc> when it isn't fucking you over
21:38:29 -!- arseniiv_ has changed nick to arseniiv.
21:38:44 <b_jonas> kmc: ouch
21:40:24 -!- arseniiv_ has joined.
21:41:12 -!- arseniiv__ has joined.
21:44:11 -!- arseniiv has quit (Ping timeout: 246 seconds).
21:44:40 -!- arseniiv_ has quit (Ping timeout: 246 seconds).
21:50:29 -!- arseniiv__ has quit (Ping timeout: 246 seconds).
22:00:59 -!- Phantom_Hoover has joined.
22:01:05 -!- Phantom_Hoover has quit (Changing host).
22:01:05 -!- Phantom_Hoover has joined.
22:06:14 <b_jonas> apparently used items are now described with the euphemism "pre-owned" rather than plain "used" or "second-hand"
22:06:57 <b_jonas> (I'm shopping on ebay.com)
22:08:42 <kmc> that's been the case for a looong time
22:08:44 <kmc> at least for cars
22:09:10 <b_jonas> kmc: I haven't been shopping online for long yet
22:09:19 <b_jonas> only for like two years so far
22:09:27 <kmc> ah
22:09:30 <b_jonas> I'm somewhat conventional and find it hard to get used to
22:09:34 <kmc> I bought my car online
22:09:36 <b_jonas> also I'm definitely not buying cars
22:09:40 <kmc> which is weird because no test drive
22:09:45 <kmc> but they had a 14 day return policy
22:09:52 <kmc> and as it turns out I love that car
22:09:59 <b_jonas> kmc: um, just because it's online you could have a test drive
22:10:11 <kmc> it was used
22:10:14 <b_jonas> even then
22:10:18 <kmc> how do you figure
22:10:55 <b_jonas> you search in the catalog of cars for sale, you contact the owner that you're interested,
22:11:13 <b_jonas> you agree with them at a time and place, and possibly pay an advance, and try the car before agreeing to take it,
22:11:33 <b_jonas> because especially for a used car there are a lot of things you may want to check directly on the car, that you can't see on photos or descriptions
22:11:36 <b_jonas> as in hidden errors
22:11:50 <b_jonas> this need not include a test drive, but it can
22:12:12 <b_jonas> depends on stuff like whether the car still has permission to run and insurance
22:12:36 <b_jonas> and whether it needs things fixed in a garage immediately after buying
22:14:21 <b_jonas> I'm buying cheap new items online, but see used ones in the listing when I search
22:14:48 <b_jonas> obviously I have to check that field that says "brand new"
22:14:56 <b_jonas> or "new (with tags)"
22:15:51 <kmc> that's not how buying cars online works
22:15:55 <kmc> it could have been thousands of miles away
22:16:00 <kmc> and, the seller does an inspection
22:16:11 <kmc> and you handle your own insurance and registration
22:16:21 <kmc> but yeah I was a little scared of getting ripped
22:16:22 <kmc> off
22:16:24 <kmc> but it was fine
22:16:30 <b_jonas> "thousands of miles" probably no, but a few hundred kilometers certainly
22:16:34 <kmc> ok
22:16:43 <b_jonas> sorry, I live in Europe, it's smaller
22:16:46 <kmc> you're once again pulling stuff out of your ass regarding things you've never done
22:17:03 <kmc> I wasn't buying on craigslist
22:17:18 <kmc> I went through a middleman that provides various services
22:17:23 <kmc> they also handled the registration for me
22:17:24 <b_jonas> ok
22:17:29 <kmc> which was convenient, although it took a long time
22:17:39 <b_jonas> so a used cars sales company
22:17:40 <b_jonas> makes sense
22:18:38 <b_jonas> sorry, I wasn't thinking of that, because my family and some co-workers bought and sold some cars and motorbikes recently, and they all bought or sold them directly to the previous or next owner, not through a used car professional
22:19:27 <b_jonas> but yes, agents handling sales of cars do exist here too
22:22:25 <kmc> eh it's ok
22:22:29 <kmc> i got pissed off unnecessarily
22:22:32 <kmc> it happens a lot :/
22:22:39 <kmc> sorry
22:23:11 -!- Essadon has joined.
22:23:13 <b_jonas> I'm not saying that either method is better
22:23:22 <b_jonas> you can't trust individual people, but you also can't trust agents
22:23:49 <b_jonas> s/people/owners/
22:24:27 <b_jonas> so in python, you can call list or tuple with an existing list as an argument to make a shallow copy, right?
22:24:40 <b_jonas> let me test to make sure it's really shallow
22:25:17 <b_jonas> yeah, shallow
22:25:18 <b_jonas> good
22:26:52 <kmc> you can call it with any iterable
22:26:54 <kmc> and yeah, it's shallow
22:30:31 <b_jonas> `` python3 <<<'a=[[4],[5]];b=list(a);a[0][0]=6;a[1]=[7];print(a,b)' # yes
22:30:32 <HackEso> ​[[6], [7]] [[6], [5]]
22:30:44 <kmc> bzzzzonk
22:31:15 <kmc> `quote
22:31:16 <HackEso> 843) <oerjan> i think the problem is you're trying to interpret finnish as logic.
22:31:19 <kmc> `quote
22:31:20 <HackEso> 1075) <oerjan> i guess the fact i won't eat bovine tongue is just tranferred cod trauma.
22:31:23 <kmc> `quote
22:31:24 <HackEso> 465) <Taneb> Maybe if you try diplomacy. <Taneb> Pointy steel diplomacy
22:41:04 -!- AnotherTest has quit (Ping timeout: 272 seconds).
22:48:16 -!- Phantom_Hoover has quit (Remote host closed the connection).
23:01:50 -!- Phantom_Hoover has joined.
23:03:17 -!- tromp has quit (Remote host closed the connection).
23:26:07 <zzo38> Someone read the story I wrote of GURPS game I played, and their idea is that Ziv should just bite off the shapeshifter's face.
23:28:08 <zzo38> But I would think that would be difficult for a few reasons.
23:38:27 -!- tromp has joined.
23:42:52 -!- tromp has quit (Ping timeout: 250 seconds).
23:58:15 -!- oerjan has joined.
←2019-03-21 2019-03-22 2019-03-23→ ↑2019 ↑all