00:00:02 -!- GeekDude has quit (Quit: WeeChat 2.1).
00:27:29 -!- GeekDude has joined.
00:32:38 -!- Lord_of_Life_ has joined.
00:35:28 -!- Lord_of_Life has quit (Ping timeout: 245 seconds).
00:35:29 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
01:09:01 <int-e> shachaf: yes on ?.
01:09:13 -!- oerjan has joined.
01:09:41 <int-e> shachaf: I may have gotten lucky because I'm still stuck on a relevant level ;)
01:12:27 <pikhq> Baba is you is great
01:17:18 <int-e> hmm you don't need a flag to reach ?
01:17:44 <int-e> anyway. almost 20 hours. so much time wasted...
01:18:23 <int-e> still less than Recursed though
01:22:05 -!- Phantom_Hoover has quit (Remote host closed the connection).
01:27:33 <zzo38> I looked it up on Wikipedia. It look like a interesting idea. In Godel,Escher,Bach also is a idea about the pieces on a chess board affecting its own rules.
01:30:28 <pikhq> zzo38: It is, and it's both presented and executed well.
01:36:17 -!- tromp has joined.
01:40:49 -!- tromp has quit (Ping timeout: 255 seconds).
01:50:58 -!- Essadon has quit (Quit: Qutting).
02:13:30 <zzo38> I wrote some ideas about my xyzabcde2 game, which is included in the source code download. Look if you are able to help with such idea (and perhaps other ideas that you may have)
02:30:36 -!- tromp has joined.
02:34:43 -!- tromp has quit (Ping timeout: 246 seconds).
02:48:03 <zzo38> I read a article about "Friendly C"; I do not agree with all of the features they propose, but I agree with some of them. Others I partially agree, or need more elaboration, or have other ideas about it, or sometimes just disagree.
02:50:36 <zzo38> https://blog.regehr.org/archives/1180 I think 1 and 2 and 3 are good (note that in Glulx, a left or unsigned right shift by negative or shift-past-bitwidth is guaranteed to produce 0, but this is not guaranteed on all computers in general); however, with 1 I should also add that there is no guarantee that it will not also equal the address of a new object too.
02:53:30 <zzo38> In the case of 10, it should be a flag to tell the compiler what to do (perhaps with a #pragma command or __attribute__). In case of 4, some computers might not trap when dereferencing a null pointer, and also side effects may be possible on some target computers, but the compiler can still assume there are no side effects (unless it is marked volatile), even if there are side effects.
02:56:31 <zzo38> I agree with 7 and 8, and with the second part of 12 (but the first part is different; it should be allowed but not mandatory that memmove and memcpy is same). I agree 14 also. With 9 I think instead the specification should guarantee that if you perform pointer arithmetic and then make the reverse of it (in the same number of steps or not), the result is same pointer as the original.
03:12:48 -!- tromp has joined.
03:17:07 -!- tromp has quit (Ping timeout: 245 seconds).
03:47:33 -!- oerjan has quit (Quit: Nite).
03:57:54 <shachaf> int-e: Oh, wait, I just realized what you did wasn't what I thought.
05:00:52 -!- tromp has joined.
05:05:34 -!- tromp has quit (Ping timeout: 255 seconds).
05:41:07 <zzo38> I look at LLVM documentation for undefined values. I think that maybe there should be a "undefrandom" instruction, which the optimizer believes generates a random number with an unspecified distribution, but the actual effect of the instruction is to do nothing (and can be compiled into nothing). This way if you write %B = undefrandom i32 %C = xor %B, %B then the result is zero.
06:49:09 -!- tromp has joined.
06:53:41 -!- tromp has quit (Ping timeout: 250 seconds).
08:03:06 -!- tromp has joined.
08:24:53 <zzo38> I don't know if anyone working in any kind of computer, is using instructions for floating point for purposes other than working with floating point numbers. Do you know?
08:30:11 -!- FreeFull has quit.
08:57:06 -!- TheWild has joined.
09:13:22 -!- TheWild has quit (Ping timeout: 245 seconds).
09:15:55 -!- TheWild has joined.
09:20:05 <b_jonas> zzo38: there are a few tricks that may count, depending on what you count as "working with floating point numbers". in some non-x86 cpus that have built-in floating point, but no instruction to find the highest bit set in a word, you can find the highest bit set using the instruction that converts an integer to a floating point, then extracting the exponent part with like three more instructions.
09:21:49 <b_jonas> in some cases, you may do integer multiplications or divisions with floating point multiplication or division instructions if the range of your numbers is just right for that to be faster. this can come up on x86 for things like alpha-compositing two pixel graphics when _both_ have an alpha channel, since then you need vector divisions with a variable divisor.
09:22:38 <b_jonas> that's not a common case though: the common case of alpha-compositing is when one of the layers have no alpha channel, and that's easier.
09:26:04 <b_jonas> in some cases, you can use floating point instructions for the instruction-level parallelism, or for the additional registers on cpus that have separate floating point registers, but this kind of optimization is usually not worth the bother
09:27:49 <zzo38> Ah, those are some stuff. Not really what I meant, but those are some tricks. (Those things do deal with floating point numbers though, rather than using floating point instructions on integers, which is what I meant.) Still, thank you for these explanations.
09:28:44 <b_jonas> on ancient x86_16, you could use the x87 instructions to format large integers to binary. you do this by loading from either an integer or a 64-bit floating point or a 80-bit floating point into the x86 register, then storing in decimal format.
09:29:23 <b_jonas> but that was only worth because the ancient x86_16 had very slow multiplication instructions
09:30:36 <b_jonas> and even then it's slow and might not be worth
09:30:56 <b_jonas> in practice it's not helpful because back then people just didn't have the x87 hardware
09:31:16 <b_jonas> and by the time everyone had it, the x86 had faster multiplication on wider integers
09:31:41 <b_jonas> oh, and of course there are ancient computers, and some modern high-level languages, that only give you floating point numbers and floating point arithmetic
09:31:51 <b_jonas> in which case of course you use those for integer stuff
09:31:59 <b_jonas> this includes programmable calculators too
09:32:59 <b_jonas> though in that case they're not really floating point _instructions_, they're floating point subroutines implemented in a simple 8-bit cpu that doesn't know what floating point means
09:37:22 -!- TheWild has quit (Ping timeout: 250 seconds).
09:49:34 -!- TheWild has joined.
10:04:41 -!- TheWild has quit (Ping timeout: 246 seconds).
10:21:51 -!- AnotherTest has joined.
10:33:22 -!- TheWild has joined.
10:44:09 -!- Phantom_Hoover has joined.
11:05:48 -!- arseniiv has joined.
12:33:17 -!- Lord_of_Life_ has joined.
12:36:02 -!- Lord_of_Life has quit (Ping timeout: 250 seconds).
12:36:07 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
12:56:02 <fizzie> Thought I'd give PulseAudio a chance again, now that (well, some years ago) they added an "avoid-resampleing = true" option -- but turns out that for whatever reason, the Chrome + YouTube combination will still pick the 48 kHz Opus stream, internally resample to 44.1 kHz, and play that back.
12:56:08 <fizzie> (I can see at chrome://media-internals that the player is using FFmpegAudioDecoder "code: opus, samples_per_second: 48000", but on the audio side the stream has "sample_rate: 44100".)
12:56:18 <fizzie> I don't think that's really PA's fault, actually it might've been even worse back on ALSA+dmix where I had the dmix output at 48 kHz; very possibly that was doing 48 -> 44.1 -> 48.
12:56:22 <fizzie> (I also don't hear any of these differences, it's more of a matter of principle.)
13:07:16 <fizzie> Actually I guess it might sort-of be PulseAudio's "fault", because AudioOutputResampler uses AudioManager::GetPreferredOutputStreamParameters to pick, and the Pulse and ALSA implementations are different. It's attempting to get the "native" sample rate from Pulse by calling pa_context_get_server_info and then using info->sample_spec.rate. I could probably change that by setting the default-sample-rate.
13:07:42 <fizzie> But I guess it's always going to resample internally (don't see any flag to avoid AudioOutputResampler), so I should just guesstimate whether 44.1 or 48 is more common on the webs.
13:10:59 <fizzie> ...uh, now the output controller has a sample_rate of 48000, but the output *stream* is still 44100. Odd.
13:26:42 <fizzie> Oh, looks like I just needed to restart Chrome.
13:27:14 <b_jonas> fizzie: maybe you had multiple audio sources running in the browser, and they had to be mixed into a common sample rate?
13:27:44 <fizzie> Could be. I don't know if it does that within the browser, or as separate streams to PulseAudio.
13:28:04 <b_jonas> fizzie: I presume it would be PulseAudio that mixes them
13:28:18 <b_jonas> or at least not the browser
13:28:35 <b_jonas> but either pulseaudio or the hardware
13:28:37 <fizzie> Well, that's easy enough to verify by just opening another tab.
13:28:52 <b_jonas> fizzie: but it can't be just any tab
13:29:00 <b_jonas> it has to be one with an audio running with different sample rate
13:29:47 <fizzie> Well, "any tab" was enough to show that they're separate streams to PulseAudio.
13:30:17 <fizzie> I guess that's sort of obvious, otherwise you couldn't assign different tabs to different playback devices.
13:32:43 <fizzie> Looks like if I open a 44.1 kHz .wav file, it's resampled in the browser to the common 48k now. Fair enough.
13:33:38 <b_jonas> but isn't 44.1 like the usual sample rate, because it was used on audio CDs?
13:33:48 <b_jonas> you know, before we started to compress audio
13:34:23 <fizzie> Yes, but I (at least for now) changed PulseAudio's default-sample-rate to 48000, so that's now what Chrome thinks is the "native" sample rate, and that's what it will output everything as, as far as I can determine.
13:35:32 <fizzie> I think I'd prefer it if it just sent the streams to PulseAudio and let that make the decision, but from the code that didn't look achievable.
13:38:39 <fizzie> Actually, again from the code, looks like that *is* what it should do normally, but if the audio player is requesting AudioParameters::AUDIO_PCM_LOW_LATENCY as the format (which seems to be the case for all media playback), it's going to use what it thinks is the "native" sample rate of the system.
13:39:15 <fizzie> https://cs.chromium.org/chromium/src/media/audio/audio_manager_base.cc?l=341-344&rcl=9a9b2ae55f6b5de259deae781c20fdc9419abe7b
13:40:29 <fizzie> (GetPreferredOutputStreamParameters -> AudioManagerPulse::UpdateNativeAudioHardwareInfo -> pa_context_get_server_info, which returns /etc/pulse/daemon.conf's default_sample_rate.)
14:14:12 -!- oerjan has joined.
14:21:48 <fizzie> Yeah, confirmed by playing something from SoundCloud that even when it's decoding a 44.1k file, Chrome will upsample to 48k. Oh well. It's not any *worse* than it was with ALSA, and at least now (a) Chrome won't be all "audio renderer error" when I forget to turn the DAC on, and (b) I don't need to change .asoundrc files if I happened to play back something local that's not at 48k.
14:30:15 -!- Sgeo__ has joined.
14:31:14 -!- Sgeo__ has quit (Read error: Connection reset by peer).
14:31:41 -!- Sgeo__ has joined.
14:33:28 -!- Sgeo_ has quit (Ping timeout: 255 seconds).
14:33:58 -!- Sgeo has joined.
14:36:55 <int-e> shachaf: oh it's ???
14:37:14 -!- Sgeo__ has quit (Ping timeout: 250 seconds).
14:55:24 -!- tromp has quit (Remote host closed the connection).
15:03:10 <int-e> oerjan: That was again about Baba is You.
15:16:57 -!- tromp has joined.
15:19:23 -!- AnotherTest has quit (Ping timeout: 250 seconds).
15:21:47 -!- tromp has quit (Ping timeout: 268 seconds).
15:26:43 -!- tromp has joined.
15:35:53 -!- Essadon has joined.
15:36:09 -!- FreeFull has joined.
15:55:28 -!- oerjan has quit (Quit: Later).
16:00:20 <esowiki> [[Talk:Infinite Vector]] https://esolangs.org/w/index.php?diff=60588&oldid=44805 * Fmease * (+4540) Add talk about the very first implementation and thereby encountered issues
16:18:38 <esowiki> [[Talk:Infinite Vector]] M https://esolangs.org/w/index.php?diff=60589&oldid=60588 * Fmease * (+17) Fix wording
16:20:09 -!- AnotherTest has joined.
16:20:16 <esowiki> [[User talk:Fmease]] N https://esolangs.org/w/index.php?oldid=60590 * Fmease * (+0) Create page
16:57:33 -!- TheWild has quit (Ping timeout: 245 seconds).
17:12:13 <esowiki> [[Infinite Vector]] https://esolangs.org/w/index.php?diff=60591&oldid=44773 * Ais523 * (+368) /* Control */ add initial-value
17:19:06 <esowiki> [[Infinite Vector]] https://esolangs.org/w/index.php?diff=60592&oldid=60591 * Ais523 * (+100) /* I/O */ how to fix the type of the input
17:19:42 -!- TheWild has joined.
17:22:52 <esowiki> [[Infinite Vector]] https://esolangs.org/w/index.php?diff=60593&oldid=60592 * Ais523 * (+215) /* Commands */ types for shift/rotate
17:28:13 <esowiki> [[Talk:Infinite Vector]] https://esolangs.org/w/index.php?diff=60594&oldid=60589 * Ais523 * (+2208) /* Very first implementation and thereby encountered issues */ I fixed one, comments on the others
17:33:37 -!- tromp has quit (Remote host closed the connection).
17:40:10 -!- tromp has joined.
17:46:12 -!- FreeFull has quit (Quit: New kernel).
17:47:19 -!- FreeFull has joined.
18:03:26 -!- tromp has quit (Remote host closed the connection).
18:09:40 -!- adu has joined.
18:15:14 -!- tromp has joined.
18:17:00 -!- Vorpal has joined.
18:46:03 -!- tromp has quit (Remote host closed the connection).
19:00:11 -!- tromp has joined.
19:02:43 <rain1> push hard up and then easy into the space
19:03:58 -!- TheWild has left.
19:14:28 -!- adu has quit (Quit: adu).
19:35:12 -!- tromp has quit (Remote host closed the connection).
19:51:38 <zzo38> I want to install NNTP server software; what do you suggest?
19:52:34 -!- sleffy has joined.
19:52:43 -!- sleffy has quit (Remote host closed the connection).
19:56:08 -!- tromp has joined.
20:39:30 <b_jonas> at least, it seems strange when I hear about it through the internet or friends. I've never been there in person.
20:44:45 -!- tromp has quit (Remote host closed the connection).
20:50:18 <kmc> america is very strange
20:50:23 <kmc> though, I think each country is strange in some ways
20:50:31 <kmc> are you thinking of anything in particular
20:52:42 <b_jonas> kmc: well, right now I'm unfair because I'm thinking of things that apply in some parts of Euroep too
20:53:40 -!- tromp has joined.
20:55:14 -!- heroux has quit (Read error: Connection reset by peer).
20:55:32 -!- heroux has joined.
20:58:21 -!- newbie78 has joined.
21:01:10 -!- Essadon has quit (Ping timeout: 250 seconds).
21:11:59 -!- tromp has quit (Remote host closed the connection).
21:14:10 -!- bobby has quit (Ping timeout: 250 seconds).
21:14:48 -!- bobby has joined.
21:21:37 -!- arseniiv has quit (Ping timeout: 255 seconds).
21:28:50 -!- bobby has quit (Remote host closed the connection).
21:30:01 -!- bobby has joined.
21:43:40 -!- bobby has quit (Remote host closed the connection).
21:44:51 -!- bobby has joined.
21:50:48 -!- tromp has joined.
21:50:59 -!- tromp has quit (Remote host closed the connection).
21:51:13 -!- tromp has joined.
21:53:01 <FireFly> Currently (well 'currently' for a rather long definition of that word, maybe) some of Europe feels plenty strange too, what with everything around Brexit
22:06:17 -!- tromp has quit (Remote host closed the connection).
22:15:49 <zzo38> I added into the Unusenet specification, an optional specification for accessing information about Unusenet over gopher.
22:21:53 -!- sebbu has quit (Quit: Quitte).
22:40:49 -!- tromp has joined.
22:43:08 -!- tromp has quit (Remote host closed the connection).
22:43:21 -!- tromp has joined.
22:49:28 -!- sebbu has joined.
23:08:16 -!- oerjan has joined.
23:51:57 -!- AnotherTest has quit (Ping timeout: 250 seconds).
23:54:14 -!- tromp has quit (Remote host closed the connection).