IRC logs for #openttd on OFTC at 2020-05-18
⏴ go to previous day
00:00:03 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEmp
00:38:35 <_dp_> measured some random games, 25-100% of monthly lag is that cargo stuff calculation for subsidies
00:40:36 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEOW
00:46:27 <FLHerne> _dp_: Is it not used by GS?
00:46:43 <FLHerne> More people use those than subsidies
00:46:50 <_dp_> FLHerne, doesn't look like it
00:48:11 <_dp_> newgrfs are a bit involved but it would be very weird for them to rely on some callback that's called randomly
00:49:47 <_dp_> and even removing that stuff will stop it from being called randomly... just less often
00:50:08 <_dp_> can a newgrf callback change game btw?
00:54:15 <_dp_> yes for game state? if so this callback is straight up desync material as it's called in gui
00:55:25 *** Kevin is now known as Guest25383
00:56:08 *** Guest25383 is now known as kamnet
00:56:31 <kamnet> I have rejoined the Matrix.
01:25:24 <FLHerne> kamnet: But we're on IRC :p
01:25:44 <FLHerne> But now I'm going to sleep
01:35:03 <kamnet> Goodnight FLHerne. And hello Supermop. :)
02:11:15 <supermop_Home_> somehow i never have the DVTs in iron horse
02:34:54 *** Wormnest has joined #openttd
03:56:11 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEnv
04:35:52 *** Gustavo6046 has joined #openttd
04:54:30 *** Yexo is now known as Guest25402
04:54:36 *** ChanServ sets mode: +o Yexo
08:03:50 *** sla_ro|master has joined #openttd
08:19:49 *** andythenorth has joined #openttd
08:21:45 <DorpsGek_III> [OpenTTD/OpenTTD] fsimonis commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfE0c
09:51:51 *** Eddi|zuHause has joined #openttd
10:04:10 *** matt21347 has joined #openttd
10:05:10 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/JfE2o
10:06:19 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #8135: Prepare for 1.10.2 release https://git.io/JfWH4
10:29:13 <_dp_> is there any convenient way to advance the save for 1 tick?
10:29:56 <Eddi|zuHause> sending unpause/pause from the console?
10:30:52 <LordAro> _dp_: some minor modifications to the debug desync code might do well enough
10:32:00 <Eddi|zuHause> slightly more elaborate or future proof would be to make ctrl+click on the pause button advance in single steps or something
10:32:18 <_dp_> just console command will be enough
10:32:44 <_dp_> though atm I don't even see a way to pause on load
10:32:47 <Eddi|zuHause> adding a console command is pretty easy
10:33:12 <Eddi|zuHause> pause on load you can hack into afterload
10:34:37 <Eddi|zuHause> but that would also be a candidate for an actual feature
10:36:28 <Eddi|zuHause> (or just make the savegame while paused)
10:44:38 *** gelignite has joined #openttd
10:58:00 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
10:58:34 *** andythenorth has left #openttd
11:22:51 <_dp_> ok, looks like it's already somewhat late to save when server receives the desync
11:23:09 <_dp_> server was 80 ticks ahead so even after advancing the game diff is still massive :(
11:23:31 <_dp_> I may have found the desync anyway
11:26:26 *** supermop_Home_ has quit IRC
11:48:33 *** ChanServ sets mode: +v tokai
11:53:45 *** arikover has joined #openttd
11:56:10 <Samu> you're becoming an expert!
13:30:10 <Eddi|zuHause> that was probably both overdue and pointless...
14:00:44 <Eddi|zuHause> so in nml "make regression", can i select a single test to run instead of all of them?
14:02:40 <_dp_> LordAro, in case you want to release 1.10.2 smth needs to be done with Town::accepted_cargo and subsides imo
14:03:36 <Eddi|zuHause> _dp_: why do you think it's that urgent?
14:03:51 <_dp_> Eddi|zuHause, because it desyncs
14:03:59 <_dp_> savegame stuff is irrelevant there
14:04:13 <LordAro> _dp_: you're not wrong
14:04:24 <LordAro> i was just making sure i had all the backported stuff in the PR
14:04:34 <LordAro> though we do need to do a release sooner rather than later
14:04:53 <LordAro> fewer bugs in a new release is better than all the bugs in an old release
14:05:22 <_dp_> it should be a relatively easy fix if we're ok breaking subsidies a bit :)
14:05:58 <_dp_> or should I say in a different way xD
14:06:22 *** ZirconiumX has joined #openttd
14:06:58 <_dp_> it's amazing how that all works actually
14:07:05 <FLHerne> Eddi|zuHause: `make -C regression 001_action8`
14:07:23 <FLHerne> (or cd regression; make 001_action8`
14:07:39 <_dp_> it maintains acceptance matrix updating it on every relevant operation (except where bugged)
14:07:47 <Eddi|zuHause> FLHerne: alright, seems to work
14:08:19 <_dp_> recalculates those matrices for each town each month in a very ineffecient way (scanning every tile 9 times doing cb calls)
14:08:26 <FLHerne> Eddi|zuHause: Why is it useful? Even on my painfully-slow laptop the tests only take 30s or so
14:08:43 <_dp_> and then subside just have 1/16 chance to use those matrices for 2 towns each month xD
14:09:05 <Eddi|zuHause> FLHerne: i added some debug output and want to reduce the scope
14:09:05 <LordAro> _dp_: i'm not sure that's something that can be backported
14:09:25 <LordAro> not that i disagree that the current implementation is silly
14:09:26 <_dp_> LordAro, it can be backported just fine as long as it stays in a savegame
14:09:54 <FLHerne> Eddi|zuHause: I think your patch is a bit silly, btw :p
14:10:18 *** supermop_Home_ has joined #openttd
14:10:29 <Eddi|zuHause> well, it's an essential part of compiling CETS
14:10:55 <Eddi|zuHause> but nobody else seems to be able to think of a use for it...
14:11:35 <FLHerne> NML already has comments, adding a weird 'comment()' block that only makes sense for your specific usecase seems wrong
14:12:42 <FLHerne> And having to patch NML's output together after the fact is a bug that should be fixed, not a usecase to encourage :-/
14:13:55 <Eddi|zuHause> well... someone once thought that including action C in NFO was a good idea
14:13:57 <_dp_> LordAro, I kind of started on pr already btw, was just mostly reading code till now
14:14:05 <_dp_> but transitioning to writing it atm :)
14:15:23 <FLHerne> Eddi|zuHause: Where does CETS live now? Devzone doesn't show any commits for a while
14:15:47 <Eddi|zuHause> depends on what you call "live" :p
14:16:21 <FLHerne> Well, where do I get a current version of the source, so I can crash my laptop with it?
14:16:41 <Eddi|zuHause> there should be all commits on devzone
14:16:49 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEMp
14:19:58 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfEDL
14:37:51 <Eddi|zuHause> there was supposed to be a small change to the source to turn it back into single-file mode, but i can't find it
14:38:50 <FLHerne> Eddi|zuHause: Yeah, I was trying to figure out how to do that
14:39:34 <Eddi|zuHause> i was hoping to find it in r734
14:39:46 <Eddi|zuHause> but it's not as obvious as i would have hoped
14:49:28 <FLHerne> Eddi|zuHause: Can I just revert 734 altogether?
14:49:44 <Eddi|zuHause> i don't think that'll work
14:50:43 <Eddi|zuHause> in scripts/files.py there's vehicle_file, which is probably the right place
14:53:55 <FLHerne> [13:52][9757][flh ~/projects/cets/]$ hg checkout default (hg)-[default|merging]-
14:53:56 <FLHerne> abort: outstanding merge conflicts
14:54:02 <FLHerne> [13:53][9758][flh ~/projects/cets/]$ hg merge --abort (hg)-[default|merging]-
14:54:04 <FLHerne> abort: no merge in progress
14:54:17 <FLHerne> And they say git is awkward and counterintuitive
14:56:41 <Eddi|zuHause> i've no clue how you handle conflicts from command line
14:58:04 *** WormnestAndroid has quit IRC
14:58:05 *** WormnestAndroid has joined #openttd
14:59:41 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8157: Fix: Incorrect save/load array size of Town::cargo_accepted https://git.io/JfES2
15:01:38 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
15:04:36 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/JfES1
15:07:34 <Eddi|zuHause> FLHerne: as far as i can recover, relevant revisions are r730 through r736 and r839
15:08:31 <Eddi|zuHause> but i don't know if anything else depends on those
15:12:42 <Eddi|zuHause> i still doubt that reverting them will do any good
15:14:55 <FLHerne> Yeah, I still get conflicts
15:15:08 <FLHerne> Some of which are non-obvious how to revert
15:17:08 <FLHerne> tbh, reverse-engineering CETS' build system just to replicate an nml bug is more work than I feel like doing just now :-/
15:17:32 <Eddi|zuHause> FLHerne: let me stirr around for a bit, and i get back to you
15:18:05 <Eddi|zuHause> FLHerne: but from what i remember, it was yacc blowing up because of python's string handling
15:18:16 <Eddi|zuHause> not sure how much nml can do there
15:18:59 <FLHerne> I've made a couple of attempts at implementing bits of the parser in C
15:19:11 <FLHerne> They didn't work terribly well, though
15:22:07 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
15:31:39 <_dp_> what's the canonical way to write constants to a savegame?
15:37:03 <Eddi|zuHause> i'm getting a weird "unexpected token" error from nmlc that i'm not sure where it's coming from
15:37:39 <Eddi|zuHause> _dp_: why would you need constants in a savegame, if they're constant?
15:37:58 <_dp_> Eddi|zuHause, to avoid bumping the savegame version
15:38:20 <Eddi|zuHause> i'm not following...
15:38:53 <_dp_> Eddi|zuHause, nvm, I though of a way already
15:39:00 <LordAro> _dp_: if we need to bump the savegame, we will
15:39:09 <LordAro> it just makes things complicated if we do it in a release branch
15:39:18 <_dp_> nah, it's just a code style problem
15:39:23 *** snail_UES_ has joined #openttd
15:44:57 <glx> <Eddi|zuHause> i'm getting a weird "unexpected token" error from nmlc that i'm not sure where it's coming from <-- maybe show the code and the error message
15:47:57 <DorpsGek_III> [OpenTTD/nml] glx22 commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
15:48:59 <Eddi|zuHause> glx: probably comes from my rebase earlier
15:51:24 <FLHerne> Eddi|zuHause: p_error in parser.py
15:51:51 <FLHerne> It means the parser reached a token that doesn't make sense in its current state
15:52:12 <FLHerne> i.e. your nml code has a syntax error, or the parser's broken
15:52:52 <FLHerne> It should tell you what the unexpected token is, and where
15:53:04 <Eddi|zuHause> yay, paste.openttdcoop.org -> " Your IP address is listed as a malicious IP. "
15:53:21 <glx> paste is long time broken
15:53:39 <Eddi|zuHause> that's the first time i hear of that
15:54:01 <glx> it's like that for months
15:57:34 <Eddi|zuHause> and i disabled all the "comment" stuff so should work with stock nml
15:58:23 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
16:01:50 <Eddi|zuHause> FLHerne: also, src/table/CETS_tracking_table.tsv might need restoring to pre-r724 for maximum effect
16:02:29 <Eddi|zuHause> (not sure if it's that easy)
16:07:37 *** gelignite has joined #openttd
16:11:39 <Eddi|zuHause> FLHerne: the file you'll be looking at would be src/cets.onml
16:18:54 <FLHerne> Eddi|zuHause: Thanks, that's working
16:21:17 <supermop_Home_> hi all, I've not yet used the gh for anything.... if i want to propose/ suggest / submit an improved sprite for opengfx - do i do that there as an issue?
16:21:48 <LordAro> supermop_Home_: a PR would be preferred, but an issue would work as well
16:22:10 <FLHerne> Eddi|zuHause: Interesting that the file isn't any *bigger* than the FIRS/Horse ones, which take a long-ish but somewhat reasonable time
16:22:56 <supermop_Home_> ok. i thought a pr was specifically for submitting some code
16:23:26 <LordAro> as far as the repo is concerned
16:23:27 <Eddi|zuHause> supermop_Home_: a PR is specifically for changing any file
16:23:43 <Eddi|zuHause> code, sprite, docs, doesn't matter
16:24:11 <supermop_Home_> i mean i guess a png is just a bunch of bits... would i submit a new sprite sheet with my sprite on it, or just my sprite?
16:24:30 <LordAro> supermop_Home_: imagine you're making a change to one of your own GRFs
16:24:54 <Eddi|zuHause> supermop_Home_: the whole file would probably be easier
16:25:13 <supermop_Home_> LordAro I've never really touched a base set before so idk if a file for just that one item (station roof) would be desirable
16:25:29 <LordAro> OGFX isn't exactly consistent
16:26:33 <Eddi|zuHause> FLHerne: i beleve r724 was specifically for reducing the file size to something that can be managed
16:27:00 <glx> hmm adding stations to nml seems complicated, they have stuff in action 0 when other features use action 2
16:27:01 <FLHerne> Eddi|zuHause: This is with your patch
16:27:30 <FLHerne> cets.onml is 11MB, which is the same as FIRS
16:27:33 <LordAro> glx: that's basically what made Yexo quit last time :p
16:27:37 <FLHerne> But it takes about 8x longer to parse
16:27:48 <LordAro> (also the new job, and life etc)
16:28:48 <Eddi|zuHause> FLHerne: yes, and reverting r724 would add some 200 vehicles on top
16:29:44 <Eddi|zuHause> i'm currently trying to see how easy it would be to reinstate those to the table, there might have been some new columns in the meantime
16:30:10 <FLHerne> But my point is that it's not purely the filesize that's the issue
16:30:28 <FLHerne> nmlc is alright with 11MB source files, just not *this* 11MB source file
16:31:04 <FLHerne> (I haven't the faintest idea why yet)
16:33:52 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M
16:36:47 <DorpsGek_III> [OpenTTD/nml] glx22 commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
16:37:51 *** Wormnest has joined #openttd
16:40:26 <DorpsGek_III> [OpenTTD/nml] FLHerne closed pull request #143: Add: Script to format the changelog for TT-Forums https://git.io/JfRax
16:40:26 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on pull request #143: Add: Script to format the changelog for TT-Forums https://git.io/JfEdq
16:41:38 *** supermop_Home_ has quit IRC
16:45:53 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on issue #139: Running regression tests litters examples with empty .nmlcache directories https://git.io/Jflcq
16:47:41 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfEdz
16:48:58 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M
16:49:18 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M
16:58:52 <Eddi|zuHause> i think i need to do some sanity checks on whatever oberhümer has been doing to this table over the last years
17:22:03 *** supermop_Home has joined #openttd
17:22:19 <supermop_Home> will i raised an issue
17:23:23 <supermop_Home> let me know if i did it wrong
17:29:25 <FLHerne> supermop_Home: Some before/after screenshots might be useful?
17:32:24 <supermop_Home> hmm i'm not sure how to get the sprite in game
17:33:00 <supermop_Home> i guess i could just photoshop it
17:42:36 <FLHerne> supermop_Home: Ideally, upload a diff of the spritesheet you've modified
17:42:44 <FLHerne> Or just the entire modified one
17:45:40 <supermop_Home> in this case its the infra08 file - so upload the whole png with these sprites changes right?
17:50:32 <FLHerne> Otherwise anyone who wants to try it out has to manually copy your changes back into the right place, which is kind of a pain
17:53:23 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl opened pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk
17:53:57 <_dp_> ez way to plant 20mil trees ;)
17:55:47 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro requested changes for pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAq
17:56:50 <Eddi|zuHause> they changed something in google docs, i can't seem to copy-paste from one table to the other anymore
17:57:32 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk
17:57:54 <LordAro> i wish GH was more consistent in automatically dismissing reviews
17:58:06 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAq
18:01:05 <glx> yeah a push dismiss approve, but not requested changes
18:01:10 <supermop_Home> FLHerne do i need to name my modified file the same as the original?
18:01:46 <LordAro> supermop_Home: if you're making a PR, yes
18:01:56 <LordAro> because otherwise the actual source code needs changes
18:02:03 <LordAro> just like making a GRF
18:03:32 <supermop_Home> ugh how do i now show the entire image when attaching it to my issue
18:04:12 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAk
18:05:45 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEAK
18:06:51 *** Speeder__ has joined #openttd
18:39:41 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfEpt
18:58:23 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl updated pull request #8159: Make subsidies scan for town cargo instead of wasting resources and risking desyncs by maintaining cargo caches https://git.io/JfE5M
19:26:19 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8160: Fix: Trees disappear completely after a few years when they're not allowed to spread https://git.io/JfEjL
19:45:53 <DorpsGek_III> - Update: Translations from eints (by translators)
19:54:57 *** Progman has joined #openttd
19:56:22 *** andythenorth has joined #openttd
20:00:41 <Eddi|zuHause> but it's not 1:87
20:29:33 *** frosch123 has joined #openttd
20:32:34 <FLHerne> supermop_Home: Hm, looking at your sprites I think we have different ideas of how that roof works :p
20:33:06 <FLHerne> supermop_Home: I've always pictured it as a series of arches perpendicular to the track
20:33:22 <FLHerne> And the longitudinal "beams" being catenaries in tension hanging between them
20:33:43 <FLHerne> (the ones that are blue in the original sprite)
20:34:15 <FLHerne> I think the original sprite makes structural sense that way, although the arches could be a bit thicker
20:34:28 <supermop_Home> there are a few structural issues with how it was drawn originally,
20:35:01 <supermop_Home> and it was ambiguous whether it was meant to be a tensile structure or a spaceframe
20:35:27 <supermop_Home> but it was much too vacuous to work as either
20:35:27 <FLHerne> - Cross-wise arches originating from pillars, in compression
20:35:42 <FLHerne> - Longitudinal catenaries between those arches, in tension
20:36:04 <FLHerne> Arch-shaped stringers, crosswise, not really sure :p
20:36:14 <FLHerne> But hanging on the catenaries
20:36:55 <FLHerne> Whereas tbh I don't really see how your new one works, it's a bit thin and a very weird shape for a space-frame
20:37:24 <supermop_Home> FLHerne the 'glass' part doesn't really work in that tensile version
20:38:10 <supermop_Home> and the parts where it droops down at the side are also kinda odd
20:38:55 <supermop_Home> thin it is but i was looking for the most expedient way to make the shape of the original sprite look more substantial
20:40:23 <supermop_Home> i think the side 'droops' should be inverted, but that's a bigger change
20:41:30 <supermop_Home> the monorail roof makes a lot more sense as a catenary to me
20:43:40 <supermop_Home> i think it may make sense or look better to subdivide the glazed panels a bit more too
20:50:39 <Eddi|zuHause> Wolf01: anything after "ethanol" really doesn't sound like anything you'd want in your body in meaningful quantities
21:00:59 <Eddi|zuHause> well, my basic school cemistry taught me "don't ingest any -ol besides ethanol" and "anything containing the word 'benzene' is probably higly cancerous"
21:01:35 <Wolf01> Probably if you mix them they get different names
21:02:37 <Eddi|zuHause> i still haven't learned the "new" print syntax in python3
21:13:19 <frosch123> Eddi|zuHause: chemistry sorts elements into two categories: "cancerous" and "probably cancerous"
21:14:07 <Eddi|zuHause> yeah, it was different back then...
21:14:29 <Eddi|zuHause> when "cancerous" actually meant something
21:16:54 <frosch123> Eddi|zuHause: which new syntax? the one added 15 years ago with "{}".format(foo), or the one added 4 years ago with f"{foo}"?
21:17:24 <Eddi|zuHause> no, the one where "print foo" became "print(foo)"
21:24:11 <FLHerne> Eddi|zuHause: The "new syntax" isn't new syntax, it's just an ordinary function call
21:24:40 <FLHerne> It's just that the weird old syntax doesn't exist anymore
21:24:59 <Eddi|zuHause> yes, that is precisely "new syntax"
21:25:50 <FLHerne> There's no syntax that wasn't already there :p
21:28:59 <Eddi|zuHause> no, they changed a completely different syntax for a new purpose. that is new syntax
21:29:37 <Eddi|zuHause> if you compare the parser output, it's completely different, ergo new.
21:32:09 *** WormnestAndroid has quit IRC
21:32:21 *** WormnestAndroid has joined #openttd
21:36:17 <andythenorth> Wolf01 I might include dihydrogen monoxide
21:36:28 <andythenorth> it's fatal if ingested in large quantities
21:36:34 <andythenorth> but desert towns could require it
21:36:39 <frosch123> it's also fatal when pure
21:37:33 <nielsm> it plays a core part in nuclear power plants
21:39:01 <andythenorth> the solid form can be incredibly dangerous
21:40:21 <FLHerne> Eddi|zuHause: The new print() is quite literally just a function call, the syntax for that is the same and used for the same purpose
21:40:48 <FLHerne> The new `print()` builtin is a semantic change, not a syntactic one
21:41:13 <nielsm> more than 300,000 deaths a year are caused by dihydrogen monoxide induced asphyxiation
21:41:53 <frosch123> eddi is basically made of it
21:43:55 <Eddi|zuHause> yeah, i like living on the edge
21:45:32 <Eddi|zuHause> FLHerne: why are you trying to convince me that changing "print" from being a statement to being a function is not a syntax change?
21:46:02 <FLHerne> It's a syntax change, but it's not new syntax :p
21:46:25 <FLHerne> No-one will ever have an excuse to call me not-pedantic...
21:46:52 <Eddi|zuHause> "change" implies "old" turned into "new".
21:48:18 <FLHerne> It's only a removal of the old syntax, there's nothing new
21:49:19 <FLHerne> You can trivially implement the `print()` function, and call it in the same way with the same syntax, in any version of Python back to the very start
21:50:16 <Eddi|zuHause> why would anyone do that? you can literally use the new syntax and it happens to work on the old syntax
21:51:08 <Eddi|zuHause> because () around an expression is a no-op
21:51:36 <FLHerne> The new builtin takes a bunch of optional arguments for various things
21:52:09 <FLHerne> That the old syntax either couldn't represent, or used very strange extra syntax for
21:54:21 <Eddi|zuHause> none of that, however, changes my habit of writing "print foo" and then wondering why it doesn't work
22:09:12 <supermop_Home> hows it going andythenorth
22:13:28 <supermop_Home> well i dropped / cracked my phone
22:25:40 <Eddi|zuHause> get a dumbphone, never worry about dropping or cracking
22:50:28 *** WormnestAndroid has quit IRC
22:51:32 *** WormnestAndroid has joined #openttd
23:26:07 *** Wormnest has joined #openttd
23:37:13 *** michi_cc has joined #openttd
23:37:13 *** ChanServ sets mode: +v michi_cc
23:39:47 *** Progman has joined #openttd
23:46:02 *** michi_cc has joined #openttd
23:46:02 *** ChanServ sets mode: +v michi_cc
23:49:39 *** sla_ro|master has joined #openttd
continue to next day ⏵
