←2019-07-27 2019-07-28 2019-07-29→ ↑2019 ↑all
00:00:52 -!- Sgeo has quit (Ping timeout: 244 seconds).
00:11:54 -!- Phantom_Hoover has quit (Ping timeout: 272 seconds).
00:14:01 -!- arseniiv has quit (Ping timeout: 246 seconds).
01:55:32 <zzo38> I found a Scrabble game called "scribble" in the package manager on my computer. Scribble was written by Brian White <bcwhite@pobox.com> and has been placed in the public domain (the only true "free"). I added a single player mode, so that if you put level 0 then you can play game by yourself.
02:26:16 -!- FreeFull has quit.
02:40:24 <esowiki> [[Talk:Swissen Machine]] https://esolangs.org/w/index.php?diff=64740&oldid=64725 * Jussef Swissen * (+291)
02:44:29 -!- xkapastel has quit (Quit: Connection closed for inactivity).
03:10:52 -!- Sgeo__ has joined.
03:13:48 -!- Sgeo_ has quit (Ping timeout: 245 seconds).
03:37:11 <int-e> The Wave: \o/ \ꙩ/ \ꙫ/ \ꙭ/ \ꙮ/
03:37:29 <int-e> Oh there's \ꚙ/ as well.
03:39:41 <shachaf> int-e: It doesn't seem easy to get a definitive answer to the question "what should my program non-C program do between _start and main?"
03:39:54 <shachaf> That rdx thing is one piece of the puzzle but there are presumably others.
03:41:10 <esowiki> [[Talk:Swissen Machine]] M https://esolangs.org/w/index.php?diff=64741&oldid=64740 * A * (+615) /* Conclusion */
03:41:24 <esowiki> [[Talk:Swissen Machine]] M https://esolangs.org/w/index.php?diff=64742&oldid=64741 * A * (+64) /* Conclusion */
03:46:48 <esowiki> [[Idea]] N https://esolangs.org/w/index.php?oldid=64743 * A * (+666) Stub page.
03:47:44 <esowiki> [[Idea]] M https://esolangs.org/w/index.php?diff=64744&oldid=64743 * A * (+0)
03:50:44 <int-e> Tricky. I would rather take off from main() instead, because presumably I want to interact with libraries that in turn use libc, so I want the C library to be fully initialized.
03:51:47 <int-e> And I'm not sure that it does all that using the __constructor__ mechanism. (I don't even know how that works on the ELF side.)
04:00:17 <esowiki> [[Idea]] M https://esolangs.org/w/index.php?diff=64745&oldid=64744 * A * (+195)
04:01:04 <shachaf> How can my compiler do that?
04:01:16 <shachaf> Do I find crt0.o and link it in or something?
04:01:43 <int-e> shachaf: Oh there's more to this than the SysV ABI. LSB plays into it as well, apparently: http://refspecs.linuxbase.org/LSB_3.1.0/LSB-generic/LSB-generic/baselib---libc-start-main-.html (I googled "libc initialization" with duckduckgo)
04:01:46 <shachaf> It seems like there should be an ABI for this.
04:01:56 <esowiki> [[Idea]] M https://esolangs.org/w/index.php?diff=64746&oldid=64745 * A * (-14) /* Instructions */
04:04:44 <int-e> hmm objdump -dr /usr/lib/x86_64-linux-gnu/crt1.o
04:06:31 <shachaf> You want things from /usr/lib/gcc/x86_64-linux-gnu/*/ as well.
04:07:08 <esowiki> [[Idea]] M https://esolangs.org/w/index.php?diff=64747&oldid=64746 * A * (-59) /* Infinite loop */
04:07:10 <shachaf> `` echo 'int main() { return 0; }' | gcc -x c - -o /tmp/true; objdump -d /tmp/true | grep '>:$' | awk '{print $2}' | xargs
04:07:11 <HackEso> ​<_init>: <.plt>: <.plt.got>: <_start>: <deregister_tm_clones>: <register_tm_clones>: <__do_global_dtors_aux>: <frame_dummy>: <main>: <__libc_csu_init>: <__libc_csu_fini>: <_fini>:
04:07:26 <shachaf> What's all this nonsense? Am I supposed to do all that?
04:08:56 <esowiki> [[Idea]] M https://esolangs.org/w/index.php?diff=64748&oldid=64747 * A * (-10)
04:10:00 <int-e> Hmm, what does csu stand for. Something boring like "C start-up" maybe?
04:10:16 <zzo38> I don't know; I have once used LLVM and just defined main, and it work, so, I don't know how to do it without main
04:11:22 <shachaf> "This directory contains the C startup code (that which calls main)." from glibc/csu/
04:11:26 <int-e> I mean, looking at https://sourceware.org/git/?p=glibc.git;a=tree;f=csu it's all connected to initialization of various things...
04:11:40 <shachaf> (From the Makefile.)
04:12:35 <shachaf> So crti/crtn stand for "initializer" and "finalizer".
04:12:59 <int-e> http://www.dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html has a fancy diagram
04:14:16 <int-e> So it seems that my idea of .init is all wrong, I thought the loader handled those... but it's libc. The loader does preinit stuff, which I wasn't aware of.
04:14:38 <int-e> (loader = interpreter = ld.so)
04:15:14 <int-e> hmm, no.
04:15:49 <int-e> I was unaware of both preinit and init stuff; only the constructors were on my radar.
04:15:53 <shachaf> It seems like the loader has to be involved.
04:16:00 <int-e> too many mechanisms...
04:22:43 <int-e> Hrm, that picture fails to explain what rdx is used for by the loader.
04:23:24 <int-e> Or edx, since they're discussing x86
04:23:29 <int-e> _32
04:23:42 <shachaf> It explains it under rtld_fini, doesn't it?
04:26:05 <shachaf> So is calling __libc_start_main required by any program that wants to use libraries that link against libc?
04:27:52 <int-e> That's what it looks like to me. It seems that *a lot* of initialization doesn't happen otherwise.
04:28:16 <int-e> All the world is libc :)
04:28:26 <shachaf> And then there's register_tm_clones and other things.
04:36:03 <shachaf> https://stackoverflow.com/questions/34966097/what-functions-does-gcc-add-to-the-linux-elf talks about these a bit.
04:39:50 <int-e> https://gcc.gnu.org/wiki/TransactionalMemory - yay yet another ABI
04:42:17 <shachaf> Why does this need to be linked into my program instead of libc?
04:45:04 <int-e> well it's a gcc feature not a libc feature, and presumably glibc doesn't use transactional memory itself?
04:45:11 <shachaf> This page says some of these things are deprecated, too.
04:45:38 <int-e> Anyway I should take advantage of being up early and go for a walk before it starts getting hot.
04:45:43 <shachaf> @time int-e
04:45:44 <lambdabot> Local time for int-e is Sun Jul 28 06:45:43 2019
04:47:18 <int-e> @metar lowi
04:47:18 <lambdabot> LOWI 280420Z VRB02KT 9999 FEW008 SCT018 BKN090 16/15 Q1001 NOSIG
04:47:36 <shachaf> @metar koak
04:47:37 <lambdabot> KOAK 280353Z 29007KT 10SM CLR 20/15 A2994 RMK AO2 SLP137 T02000150 $
04:47:45 <int-e> hmm, almost chilly...
05:22:15 <shachaf> int-e: I thought the _tm_ things were necessary when linking any library that uses the transactional memory.
05:22:18 <shachaf> Maybe not.
05:56:00 <int-e> shachaf: I expect so. But why should the C library care?
06:05:11 <shachaf> Perhaps it doesn't.
06:05:38 <shachaf> I think maybe I'll just call __libc_start_main or something and see if anything breaks.
06:05:47 <shachaf> That sounds like a good way to be confident in your software.
06:06:40 <int-e> I mean, gcc is a C compiler but in this case it's implementing its own features that need additional initialization support.
06:07:16 <int-e> I would invoke gcc as a linker, tbh. Maybe g++ if C++ stuff is involved.
06:09:29 <shachaf> That seems complicated.
06:09:31 <int-e> (partly because that's what ghc does)
06:09:37 <shachaf> And how do you cross-compile in that scenario?
06:09:53 <int-e> Ugh.
06:10:07 <int-e> I basically don't cross-compile.
06:11:33 <shachaf> Probably because every tool makes it impossible to cross-compile because they do things like that.
06:11:34 <int-e> I guess technically the OpenCL experiment involved cross compilation. The last time before that was playing with an Arduino.
06:11:42 <shachaf> Or because you unly use one platform, I guess.
06:12:24 <int-e> But if you have a gcc cross compiler for the target then that should work?
06:12:54 -!- doesntthiswork has quit (Ping timeout: 272 seconds).
06:15:16 <shachaf> I thought cross-compiling with gcc was a nightmare.
06:15:43 <int-e> I thought that was true in general, independent of gcc.
06:16:51 <int-e> But as indicated I have not really touched cross compilation.
06:17:07 <int-e> Even for the Arduino thing I used a canned Makefile which, fortunately, worked.
06:17:23 <shachaf> Maybe I should look at what Go does when it makes non-statically-linked binaries.
06:17:26 <int-e> That did involve gcc as a cross compiler.
06:18:34 <int-e> (but as a stand-alone implementation without a full-fledged C library, so a lot of *your* problems didn't really come up)
06:18:53 <int-e> (no dynamic linking either!)
06:19:22 <shachaf> I've already made an ELF file that segfaults gdb.
06:21:17 <int-e> Was that your goal? :P
06:21:18 <shachaf> It's actually pretty easy, you can make it with objcopy.
06:21:33 <shachaf> No, my goal was to make an ELF file that can be executed.
06:21:40 <shachaf> (I managed that too.)
06:22:12 <int-e> (Didn't we once find out that you can crash /bin/true by messing with localisation?)
06:22:41 <shachaf> I don't remember that.
06:23:05 <int-e> How about an ELF file that can be executed but still makes gdb crash when you attempt to load it there?
06:23:53 <int-e> (Basic idea, put garbage in some sections that only gdb really cares about... dwarf stuff, say.)
06:24:07 <shachaf> Hmm, I don't remember whether the ELF file I made loaded.
06:24:59 <shachaf> Nope, also SEGV
06:26:38 <int-e> tbf, it was /bin/true --help
06:32:22 <shachaf> So it looks like Go programs that link with libc don't call libc_start_main.
06:33:13 <int-e> Go, be evil.
06:34:02 <shachaf> But what do they do instead?
06:34:06 <shachaf> I should probably just do that.
06:34:12 <shachaf> https://golang.org/src/runtime/asm_amd64.s
06:35:03 <int-e> what assembly flavor is that...
06:35:07 <shachaf> Hmm, maybe I'm wrong.
06:35:12 <shachaf> Plan 9 assembly, obviously.
06:35:57 <int-e> Hmm I guess actually I'm wondering about the register naming.
06:36:21 <shachaf> I think the register sizes are implied by the instruction names?
06:37:41 <shachaf> Recently I was writing a bit of x86 code by hand and I was confusil until I remembered someone said octal would be better than hexadecimal.
06:37:48 <shachaf> Then I was a bit less confusil.
06:38:22 <int-e> what does the (SB) do?
06:38:47 <int-e> ...Oh is that a register...
06:39:44 <shachaf> https://golang.org/doc/asm
06:39:51 <shachaf> "The SB pseudo-register can be thought of as the origin of memory, so the symbol foo(SB) is the name foo as an address in memory."
06:42:22 <shachaf> So that file defines main to be called by libc, but as far as I can tell that's not being used on a compiled binary.
06:57:29 <int-e> shachaf: https://golang.org/src/cmd/cgo/doc.go ... have a look at lines 698ff. It seems that gcc is involved in the middle of the process.
06:58:34 <int-e> __libc_start_main is mentioned but it's not clear by what mechanism it would actually be called.
07:00:23 <int-e> (that means it's still possible that it isn't called)
07:30:54 <int-e> shachaf: this may disappoint you, but go will use gcc or clang as a linker if shared libraries are involved somehow.
07:32:39 <int-e> https://golang.org/src/cmd/link/internal/ld/config.go#L224
07:33:40 <int-e> (plus documentation for `link`, which says "Set the external linker (default "clang" or "gcc")." for the -extld flag.)
07:33:51 <shachaf> int-e: I didn't see it executing gcc in the strace output, and I didn't see libc_start_main in the output of objdump -d
07:34:21 <int-e> hmm did you do strace -f
07:34:29 <shachaf> Admittedly it is passing -extld=gcc to `link`.
07:34:38 <shachaf> Yes.
07:35:49 <int-e> Maybe I'm misinterpreting ctxt.linkShared.
07:35:52 * int-e shrugs
07:35:57 <int-e> I will stop anyway
07:37:07 <shachaf> Maybe it's being cached somehow?
07:51:51 <shachaf> Anyway the entry point is certainly _rt0_amd64_linux
07:57:57 -!- Lord_of_Life has quit (Ping timeout: 245 seconds).
08:00:21 -!- Lord_of_Life has joined.
08:01:40 -!- nfd9001 has joined.
08:15:37 <\oren\> the BDF format is apparently so old that BDF files were "typically distributed on nine-track tapes"
08:16:21 <\oren\> why one would use a text-based format rather than binary in that era, I don't know
08:18:09 <int-e> so that they could be input using punched cards maybe?
08:18:29 <\oren\> ah yeah, that would explain it
08:18:41 <shachaf> What's the benefit of bitmap font formats?
08:19:00 <\oren\> They are easy to edit
08:19:26 <\oren\> or at least, that's my main reasoning
08:20:57 <int-e> \oren\: Maybe punched cards are too old, but even so I suspect being able to edit bitmaps in a text editor was useful.
08:22:51 <int-e> Though, hmm. It's using hex encoding. That's inconvenient.
08:23:09 <\oren\> I am currently working on making my BDF-handling programs more general, rather than totally specific to my neoletters font
08:23:48 <\oren\> They should be capable of handling any number of rows and up to 32 columns of pixels
08:32:09 <shachaf> \oren\: have you considered making a signed distance field font instead hth
09:28:35 -!- Frater_EST has joined.
09:39:58 <shachaf> `` file /bin/true
09:39:58 <HackEso> ​/bin/true: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9ae82394864538fa7b23b7f87b259ea2a20889c4, stripped
09:40:30 <shachaf> Is it a shared object (rather than an executable) because it's a position-independent executable?
09:41:03 <int-e> `` ldd /bin/true
09:41:04 <HackEso> ​linux-vdso.so.1 (0x0000007fbffff000) \ libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000000004042e000) \ /lib64/ld-linux-x86-64.so.2 (0x0000000040000000)
09:41:29 <shachaf> `` readelf -h /bin/true | grep -i entry
09:41:29 <HackEso> ​ Entry point address: 0x1670
09:41:46 <shachaf> That doesn't look like an absolute entry point.
09:42:05 <shachaf> So that's pretty neat. I guess I want my programs to be position-independent.
09:42:14 <int-e> Oh, I get the question, hmm.
09:42:36 <int-e> `` file --version
09:42:37 <HackEso> file-5.30 \ magic file from /etc/magic:/usr/share/misc/magic
09:42:49 <shachaf> I imagine that's much trickier if you're doing static linking.
09:43:14 <int-e> here it says, /bin/true: ELF 64-bit LSB pie executable, with file-5.37 (though technically iot's the `magic` file that's more important...)
09:43:27 <shachaf> What does readelf say?
09:43:44 <shachaf> `` readelf -h /bin/true | grep -i type
09:43:45 <HackEso> ​ Type: DYN (Shared object file)
09:44:33 <shachaf> `` echo $'.globl _start\n_start: int3' > /tmp/test.s && as -o /tmp/test.o /tmp/test.s && ld -o /tmp/test /tmp/test.o && file /tmp/test
09:44:34 <HackEso> ​/tmp/test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
09:46:46 <shachaf> https://github.com/file/file/commit/6876ebadcdf27224b3ffa9dfa4343127aa97c9b2
09:46:50 <shachaf> Looks like a pretty recent change.
09:48:30 <shachaf> int-e: Does it just print that because it has +x permission?
09:54:26 <int-e> shachaf: maybe but then please explain why file -L /lib/x86_64-linux-gnu/libc.so.6 says "shared object"
09:55:14 <shachaf> What about the thing it links to?
09:55:28 <shachaf> Oh, that's -L
09:56:00 <shachaf> Well, my version of file isn't even new enough to say "pie executable"
09:58:22 <int-e> Hmm, no, 'x' must be something else.
09:58:35 <shachaf> Probably.
10:05:46 <shachaf> I'm also confused that it says leshort when e_type is a one-byte value.
10:06:01 <shachaf> The last time I wrote magic entries I didn't enjoy it.
10:09:41 <int-e> well, you got the meaning of 'x' right.
10:09:58 <int-e> https://github.com/file/file/commit/5b49de03a239c6765b6b6858d56827a021370b07#diff-dde49634c7a5cf692df46037d67d8c2eR480-R488
10:11:44 <int-e> which means I'm pretty confused now
10:12:27 <shachaf> Did you try it on the link target to be sure?
10:13:06 <int-e> I actually made a copy of /bin/true, removed the x, and it still says "pie executable"
10:13:31 <shachaf> Hmm.
10:13:48 <shachaf> Also is this the one use of ${ in the entire magic database?
10:14:26 <int-e> possibly? the feature was introduced one or two patches before the elf change
10:15:13 -!- arseniiv has joined.
10:15:14 <shachaf> Ugh, autoconf/automake is such a scow
10:15:19 <int-e> certainly looks that way
10:15:23 <shachaf> It makes me miserable every time I accidentally read any of it
10:15:24 <int-e> (re: x)
10:15:57 <shachaf> I know I call things scow sometimes but I think this is a pretty legitimate use
10:19:09 <shachaf> Anyway this is a real mystery now.
10:19:16 <shachaf> If only I had a more recent version of file.
10:25:09 <shachaf> Oh, I guess I can get it from Nix.
10:25:27 <int-e> ah, there's more magic
10:25:46 <esowiki> [[Bauberqueue/bauberqueue.py]] M https://esolangs.org/w/index.php?diff=64749&oldid=64378 * Erikkonstas * (-9)
10:26:00 <int-e> which overrides the file mode for ELF files
10:26:58 <int-e> https://github.com/file/file/blob/master/src/readelf.c modifies ms->mode in a couple of places.
10:27:33 <shachaf> Yikes. OK.
10:28:43 <shachaf> `` readelf -a /bin/true | grep FLAGS_1
10:28:44 <HackEso> ​ 0x000000006ffffffb (FLAGS_1) Flags: PIE
10:30:04 <shachaf> I wonder where this is specified?
10:36:13 <shachaf> https://cirosantilli.com/elf-hello-world#df_1_pie talks about it and links to a description
10:36:18 <shachaf> Man, this is ridiculous.
10:37:21 <shachaf> `` readelf -h /lib64/ld-linux-x86-64.so.2 | grep -i entry
10:37:22 <HackEso> ​ Entry point address: 0xc20
10:37:46 <shachaf> Even ld-linux is randomized?
10:37:55 <int-e> It looks like this elf specific hack was initially introduced just for ", stripped" (checking for the absence of a particular type of section is too hard for the simple 'magic' logic)
10:37:57 <shachaf> I think I'm a bit confused about how ASLR works.
10:38:23 <shachaf> It seems the kernel decides to randomize based on an ELF file calling itself DYN.
10:40:22 <int-e> Hmm, on a fundamental level that's nevessary: ld.so remains mapped executably, and may contain useful functions and ROP gadgets.
10:40:30 <shachaf> Right.
10:40:41 <shachaf> But then why would the kernel only randomize DYN files?
10:40:46 <shachaf> Can static executables get randomized?
10:42:43 <int-e> Hrm, depends on details of the ELF format that I don't want to check...
10:44:08 <shachaf> https://stackoverflow.com/a/55704865 says "The Linux kernel 5.0 determines if ASLR can be used based on ET_DYN"
10:46:09 <shachaf> https://github.com/torvalds/linux/blob/v5.0/fs/binfmt_elf.c#L956
10:46:26 <shachaf> "There are effectively two types of ET_DYN * binaries: programs (i.e. PIE: ET_DYN with INTERP) and loaders (ET_DYN without INTERP, since they _are_ the ELF interpreter)."
10:46:31 <shachaf> thanks, linux. thinux.
10:47:36 <shachaf> Oh, well, that doesn't say what I thought it did.
10:48:27 <shachaf> But the gist of it seems the same.
11:07:59 -!- Frater_EST has left.
11:11:25 -!- Phantom_Hoover has joined.
11:39:12 <int-e> @metar lowi
11:39:12 <lambdabot> LOWI 281120Z 07003KT 030V170 9999 -SHRA FEW025 SCT050 BKN070 20/16 Q1001 TEMPO SHRA
11:39:35 <int-e> not hot today. it's raining actually.
12:05:41 -!- FreeFull has joined.
12:28:41 <shachaf> The PE machine identifier for x86-64 is 0x8664
12:57:16 <int-e> have a look at Intel's PCI vendor id some day
12:57:48 <int-e> (it's 0x8086)
13:08:03 <shachaf> That doesn't use the x, though.
13:10:32 <int-e> the 0x isn't part of the ID anyway
13:19:26 -!- Sgeo__ has quit (Read error: Connection reset by peer).
13:19:54 -!- Sgeo__ has joined.
13:31:53 -!- xkapastel has joined.
14:06:44 <esowiki> [[Sidex]] M https://esolangs.org/w/index.php?diff=64750&oldid=64708 * A * (+189)
14:10:28 <esowiki> [[Brainfuck extensions]] M https://esolangs.org/w/index.php?diff=64751&oldid=61455 * A * (+30)
14:17:08 <esowiki> [[Sidex]] https://esolangs.org/w/index.php?diff=64752&oldid=64750 * A * (+1) Oops
14:30:40 <fizzie> Intel also has the "8086F2" MAC OUI, which may or may not be a coincidence. (They have many others too.)
14:36:49 <esowiki> [[Idea]] https://esolangs.org/w/index.php?diff=64753&oldid=64748 * A * (+109)
14:40:13 <shachaf> Next you'll tell me they have it in their CPUID
14:49:00 <int-e> shachaf: I don't know, do they?
14:50:06 <int-e> > map length . words $ "GenuineIntel AuthenticAMD"
14:50:12 <lambdabot> mueval-core: Time limit exceeded
14:50:17 <int-e> ah
14:50:18 <int-e> > map length . words $ "GenuineIntel AuthenticAMD"
14:50:21 <lambdabot> [12,12]
14:50:45 <int-e> that's the only part of cpuid I tend to remember
14:50:47 -!- Frater_EST has joined.
14:51:06 -!- Frater_EST has left.
15:10:01 <shachaf> int-e: Oh man, https://www.cs.stevens.edu/~jschauma/631A/elf.html
15:10:14 <shachaf> So many things.
15:17:55 <esowiki> [[Talk:Sidex]] https://esolangs.org/w/index.php?diff=64754&oldid=64705 * Areallycoolusername * (+194)
15:40:17 -!- Frater_EST has joined.
15:40:32 -!- Frater_EST has left.
15:45:27 -!- Sgeo__ has quit (Ping timeout: 245 seconds).
15:59:19 <esowiki> [[Talk:Sidex]] https://esolangs.org/w/index.php?diff=64755&oldid=64754 * Arseniiv * (+588) /* Concatenative */ new section
16:54:30 -!- Sgeo has joined.
16:55:03 <Sgeo> You know what would be nice? A non-dying Internet connection. And a chat platform that doesn't spam people when someone happens to have a dying Internet connection.
16:58:48 <kmc> someone's salty
16:59:09 <kmc> Sgeo: I rent a cheap VPS, run irssi there and connect with mosh from both my laptop and phone
16:59:27 <kmc> it's very convenient and only rarely disconnects
16:59:45 <kmc> only when linode reboots my machine, or i have to update irssi
17:30:39 -!- moei has joined.
17:58:30 -!- user24 has joined.
18:08:48 -!- doesntthiswork has joined.
18:19:06 -!- dont-panic has joined.
18:19:17 <dont-panic> meow?
19:03:36 -!- user24 has quit (Quit: Leaving).
19:10:33 -!- arseniiv has quit (Read error: Connection reset by peer).
19:10:50 -!- arseniiv has joined.
19:33:17 -!- lynn has quit (Read error: Connection reset by peer).
19:33:37 -!- lynn has joined.
20:00:02 -!- Lord_of_Life has quit (Ping timeout: 245 seconds).
20:01:03 -!- Lord_of_Life has joined.
20:29:37 -!- Googied has joined.
20:31:15 -!- Googied has left ("Leaving").
20:43:49 <esowiki> [[Renumbering]] N https://esolangs.org/w/index.php?oldid=64756 * DoggyDogWhirl * (+1839)
20:43:54 <esowiki> [[Renumbering/Python Implementation]] N https://esolangs.org/w/index.php?oldid=64757 * DoggyDogWhirl * (+1486)
21:02:51 -!- Sgeo_ has joined.
21:05:52 -!- Sgeo has quit (Ping timeout: 245 seconds).
21:29:09 <esowiki> [[User:DoggyDogWhirl]] https://esolangs.org/w/index.php?diff=64758&oldid=64682 * DoggyDogWhirl * (+18)
21:31:38 -!- xkapastel has quit (Quit: Connection closed for inactivity).
21:31:52 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=64759&oldid=64646 * DoggyDogWhirl * (+18)
21:32:07 -!- dont-panic has quit (Ping timeout: 258 seconds).
21:36:23 -!- Sgeo__ has joined.
21:39:07 -!- dont-panic has joined.
21:39:47 -!- Sgeo_ has quit (Ping timeout: 268 seconds).
21:56:18 -!- atslash has quit (Quit: Leaving).
22:04:05 <zzo38> What is the command in Perl to count how many copies of a letter can be found in a string?
22:34:53 -!- xkapastel has joined.
22:35:23 -!- moei has quit (Quit: Leaving...).
23:27:46 -!- arseniiv has quit (Ping timeout: 272 seconds).
23:35:27 -!- Lord_of_Life has quit (Ping timeout: 245 seconds).
23:40:46 -!- Lord_of_Life has joined.
23:55:38 -!- ais523 has joined.
23:56:20 <ais523> zzo38: there isn't a dedicated command, but if you use code like $string =~ y/x/x/ to replace the letter with itself in the string, the return value is the number of replacements (and the string doesn't actually change); for a hardcoded letter, that's probably the shortest and clearest way to do it
23:56:25 <zzo38> Sgeo: If you do not want that spam then you should filter it out by your client.
23:56:46 <zzo38> ais523: As it turns out I asked on ifMUD and received a suitable answer there, so I did what they said and it work.
23:56:59 <ais523> was it the same answer or a different one?
23:57:27 <ais523> hmm… a general method might be to split the string on the letter, count the number of components in the result, and subtract 1
23:57:59 <Sgeo__> zzo38, it's other people complaining at me in one of the channels I'm in
23:58:19 <zzo38> Their answer was: $count = () = ($str =~ /$letter/g)
23:58:59 <ais523> I'm a bit surprised that =()= works
23:59:04 <ais523> although I can see logical rules behind which it would
23:59:13 <zzo38> I asked because I was modifying a Scrabble game in Perl. I added a "count" command, to count how many letters remain according to your point of view, so the letters in opponent's hand have to added back in to the count.
←2019-07-27 2019-07-28 2019-07-29→ ↑2019 ↑all