IRC logs for #openttd on OFTC at 2020-05-02
⏴ go to previous day
00:13:57 <TrueBrain> glx: or does rsplit exist in Python?
00:14:05 <TrueBrain> On mobile, sorry :p
00:14:17 <TrueBrain> rsplit(.., 3) would work too
00:15:03 <TrueBrain> Ah, seems to exist :)
00:15:09 <glx> but PEP440 doesn't want - :)
00:15:43 <TrueBrain> What ... has that to do with PEP 440? I am talking about the Python code :p
00:16:05 <glx> so anyway I need to convert 0.5.1-RC1 to 0.5.1rc1
00:16:13 <TrueBrain> Honest question btw, I am missing something :)
00:16:32 <TrueBrain> Ah! Well, that at least needs a comment :p
00:17:56 <TrueBrain> I would still suggest an rsplit. After that check for dash in tag, and fix up the tag? Might be easier to understand for future us that way?
00:18:29 <glx> yes would be cleaner to split correctly and fix
00:18:43 <TrueBrain> But please add a comment for sure :D
00:19:04 <TrueBrain> Why do we have so many ways to make versions :p :D
00:31:08 <TrueBrain> You don't want a comment to state why you do this? (I am fine both ways)
00:44:30 <glx> hmm I should quickly try a fake release in my fork, just to be sure :)
00:54:14 *** supermop_Home has joined #openttd
01:38:08 <FLHerne> glx: Edge-case with the new version of the versioning
01:38:45 <FLHerne> If I've made changes to a tagged version, in a git repository, but without committing
01:39:07 <FLHerne> It generates a version like "0.42.0m", which setuptools complains is invalid
01:39:19 <FLHerne> I don't know if this is worth caring about
01:39:24 <glx> but it's a modified release so not a release :)
01:39:46 <glx> I considered it's ok like that
01:50:15 <LordAro> tbh i don't really care about the non-tagged version being "invalid" at all
01:50:21 <LordAro> it's not like it matters
01:50:36 <DorpsGek_III> [OpenTTD/nml] glx22 opened pull request #115: Fix #112: prevent setup.py regeneration for source package https://git.io/Jf3ZN
01:55:36 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #115: Fix #112: prevent setup.py regeneration for source package https://git.io/Jf3ZN
05:02:42 *** Wormnest has joined #openttd
08:20:52 *** andythenorth has joined #openttd
08:22:20 *** Progman has joined #openttd
08:37:31 *** WormnestAndroid has quit IRC
08:37:44 *** WormnestAndroid has joined #openttd
09:16:02 *** sla_ro|master has joined #openttd
09:33:47 <Wolf01> Does he have a husband?
09:37:32 <DorpsGek_III> [OpenTTD/nml] matthijskooijman approved pull request #115: Fix #112: prevent __version__.py regeneration for source package https://git.io/Jf30t
09:39:57 <andythenorth> I like the art style
10:01:05 <Flygon> Well, this's annoying.
10:01:23 <Flygon> I have a train that doesn't want to route to a station that it has a clear route to.
10:05:13 <Wolf01> Missing catenary somewhere?
10:05:25 <Flygon> If I force it to skip a waypoint.
10:05:31 <Flygon> It WILL go to the platforms I want it to go to.
10:05:37 <Wolf01> We need an overlay which activates with the convert tool
10:05:47 <Flygon> So I think something involving waypoint routing is going weird.
10:06:04 <Wolf01> Highlights in red the tracks of a different type
10:06:18 <Wolf01> And yellow the different but compatible ones
10:10:27 <Flygon> If the issue happens again, I'll take screenshots.
10:10:39 <Flygon> I can probably try and work around it anyway.
10:14:28 <Flygon> I solved the issue by. Not solving it. It's a pathfinding bug.
10:14:38 <Flygon> I just made all the waypoints to the platforms the same distance apart.
10:14:49 <Flygon> Rather than some being 4 tiles away, and others being 14 tiles away.
10:15:10 <Flygon> Also I just realized that since this is the jgrpp, this is probably the wrong channel to muse. :D
10:16:40 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on issue #8093: Regular server desynchronisations from clients https://git.io/JfkmV
10:35:21 <DorpsGek_III> [OpenTTD/nml] TrueBrain commented on pull request #115: Fix #112: prevent __version__.py regeneration for source package https://git.io/Jf3EZ
10:44:48 <DorpsGek_III> [OpenTTD/nml] TrueBrain requested changes for pull request #115: Fix #112: prevent __version__.py regeneration for source package https://git.io/Jf3E2
12:11:36 *** Wormnest has joined #openttd
13:28:19 *** frosch123 has joined #openttd
14:42:32 <andythenorth> was nml released? :)
14:51:40 <glx> not yet, I need to rework #115
15:14:05 <FLHerne> glx: I'm not sure 115 is the right fix?
15:14:47 <FLHerne> glx: If I understand correctly, the problem is that the unpacked nml source is inside a different git repo
15:15:24 <FLHerne> In which case isn't the right fix to check whether the root of the current git repo is where it's expected to be, and abort otherwise?
15:17:08 <FLHerne> blathijs: Is my understanding ^ of 112 correct? ;-)
15:17:30 <glx> it's hard to check if it's a nml repo I think
15:23:11 <TrueBrain> I really would suggest not going to route :)
15:23:29 *** supermop_Home_ has joined #openttd
15:23:51 <supermop_Home_> andythenorth I need some of that better living over here
15:24:20 <TrueBrain> normally, what you want, after packaging a tarball, that any git-info is removed
15:24:23 <TrueBrain> so no .git folder nothing
15:24:29 <TrueBrain> and that is the moment you want to use a pre-defined version
15:24:54 <TrueBrain> so still doing any form of VCS detection after someone unpacks a tarball, is asking for a bit of trouble, one way or the other
15:26:02 <glx> I think my idea to add the "release=" line is ok, just the way to set the value is wrong
15:26:53 <TrueBrain> not sure; I think hooking into the 'build' command is the more clean way, but in the end, I personally don't really care :) Just as long as you document your choice ;) And if possible, don't like it to GitHub Actions :)
15:28:48 <TrueBrain> as, lets face it, we are going to have this wrong a few more times anyway :P Pretty sure we will find an edge case with the OpenTTD system one of these days too :D
15:31:04 *** hkneoh is now known as Foveafoxy
15:40:14 *** Foveafoxy has left #openttd
15:40:17 *** Foveafoxy has joined #openttd
15:40:19 *** Foveafoxy has left #openttd
16:15:51 <Samu> I need a pathfinder expert. What is "estimate_multiplier" supposed to do? I just implemented it on the pathfinder and it magically became fast!
16:42:35 *** Wormnest has joined #openttd
16:48:06 <Samu> this estimate multiplier is absolutely magic!
16:48:25 <Samu> takes 52 days only to pathfind from 1,1 to 4094,4094
16:48:56 <nielsm> yes it's going to be faster when it makes assumptions and guesswork and doesn't try to be perfect
16:50:08 <Samu> took a year to actually build the canals
16:50:17 <Samu> much longer than pathfinding
16:50:54 <nielsm> yeah you probably can't assume the found path remains valid for that time
16:54:20 <nielsm> what might be a better idea is maybe make a very rough estimate path as a guide, then make more exact sub-paths along the route while constructing
16:57:41 <Samu> got a crash, wondering if it also crashes in 1.10.1
17:06:38 <Samu> openttd.exe!SQInstance::Release() Line 145
17:06:38 <Samu> at d:\a\1\s\src\3rdparty\squirrel\squirrel\sqclass.h(145)
17:07:14 <Samu> looks like path was too long?
17:09:04 <Samu> no crash log files generated :(
17:09:36 <glx> for me it's the usual memory crash
17:10:29 <Samu> it didn't use much memory at all
17:10:59 <Samu> gonna try on a 2048x4096 map
17:13:13 <Samu> i no longer have the pathfinder caching
17:27:21 <Samu> that jargon makes it too complicated for my head
17:31:44 <michi_cc> Samu: If you compare that animation with the one from the earlier example sections, the difference is quite visible.
17:32:53 <Samu> ah, so that's what estimated multiplier do?
17:36:11 <FLHerne> Does anyone actually use the "line directive" support in nml?
17:38:03 <FLHerne> Removing it, and LinePosition in favour of just integers, reduces memory usage and parse time by 10% each
17:39:48 <andythenorth> what does it do?
17:40:57 <frosch123> FLHerne: yes, all pnml projects do
17:42:01 <frosch123> 5 years ago, i would have said that's the majority of projects, no idea today
17:42:06 <frosch123> opengfx certainly is
17:43:57 <frosch123> ofc, it's only used when there is something wrong :)
17:44:36 <FLHerne> andythenorth: Allows nml to tell you the correct original source file and line, even when they've been munged together
17:45:16 <FLHerne> Using __slots__ on Position and its subclasses reduces total memory usage by ~5%, with no change to compile time
17:54:30 *** erikandre has joined #openttd
17:54:59 <erikandre> Would there be a deb package for ubuntu 20.04 (LTS) with 1.10.1 ?
17:55:05 <frosch123> things start to get confusing... two people making similar newgrf sets have similar openttd/github names :)
17:55:29 <erikandre> Ive tried to install openttd with the apt-get tool. but there is only 1.9.3 (and my friend that host gameplay is on 1.10.1
17:56:36 <LordAro> erikandre: we could (theoretically) make a deb file for 1.10.1, but it's not up to us to get things into the official apt repos
17:56:48 <LordAro> they're usually frozen anyway
17:56:55 <frosch123> the official debian 1.10.1 will take another week or so
17:58:25 <erikandre> I thought that the deb file for 18.04 was gonna be possible to install on 20.04 LTS also
17:58:36 <erikandre> but of course i was wrong.
17:58:57 <LordAro> yeah, we probably need to add 20.04 to our release process now
17:59:05 <LordAro> but it wasn't released when 1.10.1 was :p
17:59:12 <Eddi|zuHause> no, those versions were never compatible with each other
18:00:40 <erikandre> its complaining about a Dependency is not satisfiable: libicu60 (>= 60.1-1~)
18:01:07 <LordAro> yeah, icu is always the incompatible one
18:02:14 *** WormnestAndroid has quit IRC
18:02:26 *** WormnestAndroid has joined #openttd
18:02:46 <erikandre> could it be possible, to ask you very kindly for a 1.10.1 deb file ? ;)
18:02:48 <andythenorth> FLHerne oh so it's the feature that tells me the error is in the wrong place?
18:02:53 <andythenorth> I hate that feature
18:03:03 <andythenorth> I always wondered why it was broken
18:03:37 <andythenorth> nmlc often gives me useless filenames and line numbers for parse errors
18:03:47 <andythenorth> as though it's working with a CPP includes compile
18:04:26 <FLHerne> If you're not using `# line [blah] or `# <number> <filename> [blah]` in your source, it does nothing
18:04:53 <andythenorth> ok so I might be conflating it with something else
18:05:11 <andythenorth> why would anyone number source in nml?
18:05:37 <FLHerne> " useless filenames and line numbers for parse errors" sounds like you're triggering it by accident somehow
18:05:51 <andythenorth> I haven't seen it for a while
18:06:27 <andythenorth> I removed all the CPP #include stuff, might not have seen it since then
18:06:35 <FLHerne> You don't have any such directives in current FIRS/Horse
18:06:52 <FLHerne> "CPP #include stuff" would do that
18:07:04 <Wolf01> Oh, finally a modded bus/tram station in transport fever 2
18:07:08 <FLHerne> Because the CPP generates those directives when it does includes
18:07:11 <andythenorth> so one minor reason I got rid of it is that it gives junk errors
18:07:20 <andythenorth> it makes debugging ridiculously hard
18:07:24 <FLHerne> I don't see why they'd be junk though
18:07:41 <FLHerne> If the CPP is including includes, they should be right :P
18:07:58 <andythenorth> could have been EBKC
18:08:13 <andythenorth> I guess there are all those pnml projects though
18:08:27 <andythenorth> forums often directs people to copy an existing pnml project
18:08:31 <erikandre> So, Until debian pushes 1.10.1 i guess i have to try build the program by source , Make make insTALL and all that other crap
18:08:49 <andythenorth> FLHerne probably have to keep it :(
18:12:46 <erikandre> Everything is better in windows. it just works.
18:13:19 <erikandre> If it had not been for det crappy windows driver and blackscreen in windows. i would have still got windows on my laptop.
18:14:26 <Wolf01> <erikandre> Everything is better in windows. it just works. <- also on linux, just install a lot of dependencies and install packages from the sites instead of the package manager
18:18:17 <FLHerne> Wolf01: Well, OTTD doesn't have the "generic" binaries anymore
18:18:39 <andythenorth> FLHerne compile time flag to suppress line number crap? :P
18:19:11 <FLHerne> andythenorth: Wouldn't work, needed at lexer generation time
18:19:41 <FLHerne> You could have a flag that just disabled the behaviour
18:22:55 <LordAro> erikandre: i think most linux users would violently disagree with "windows just works"
18:23:05 <LordAro> i'm on windows right now, and i certainly do
18:24:29 <andythenorth> nothing just works
18:25:00 <andythenorth> macos used to 'just work' for a period of about 7 years, as long as you only used Apple and Adobe stuff, and nothing complicated, and you didn't want to sync your non-Apple phone
18:25:05 <andythenorth> and even that stopped
18:30:44 <_dp_> lol, yeah, windows just works until it doesn't xDDD
18:33:42 <_dp_> though kind of starting to be the case with linux too sadly :(
18:33:52 <_dp_> hard to find good manuals amid the gui crap
18:37:47 *** Gustavo6046 has joined #openttd
18:44:24 <LordAro> glx: how do other python packages do it? this can't be a hard problem
18:59:34 *** WormnestAndroid has quit IRC
19:00:34 *** WormnestAndroid has joined #openttd
19:06:31 <glx> I managed to always use content of __version__.py for setup.py unless the file doesn't exist
19:07:09 <glx> that's ok for compile farm, but for local version it's annoying to have to remove a file to test stuff
19:09:50 <FLHerne> glx: Is there a hook so setup.py can know whether it's running `sdist` or not?
19:10:05 <FLHerne> I was reading the setuptools docs, but they're awful :-(
19:11:45 <FLHerne> I mean, if it's running `sdist` it should set the version permanently
19:12:07 <glx> other packages need the permanent version too
19:12:18 *** Wormnest has joined #openttd
19:14:04 <glx> and yes setuptools doc is not very helpful
19:14:52 <glx> and source code doesn't help either as it extends distutils so you have to navigate in 2 source trees
19:19:59 <glx> and even if I can force the regeneration for the right commands it will still use the previous generated version in setup() call
19:21:33 <LordAro> glx: i'd strongly recommend just making use of some other module, like setuptools_scm
19:21:38 <LordAro> there's no point reinventing the wheel here
20:32:00 <andythenorth> are we doing translations via PRs?
21:56:42 <andythenorth> planetmaker ^ redmine is quietly 500-ing :)
22:00:32 *** Wormnest has joined #openttd
22:23:50 *** gelignite has joined #openttd
23:23:06 <blathijs> FLHerne: Re you earlier question: THat it is in a different git repo is not the problem, that just exposes the problem. The problem is IMHO that a release tarball actually looks at git data in the first place.
23:25:39 <blathijs> glx: I thikn the ideal solution would be if __version__.py was generated during setup.py only inside the build directory, as TrueBrain suggested, so there is no need to remove it afterwards (in fact, there is never a reason to generate __version__.py outside of build in the git checkout itself, since there you can always just re-detect from git anyway)
23:28:08 <glx> I don't think it's possible, even setuptools_scm puts a file in source
23:29:47 <TrueBrain> setuptools cmdbuild is often used for this
23:29:54 <TrueBrain> take over the build step, and you can do ANYTHING :D
23:30:07 <TrueBrain> cmdclass -> build, I believe
23:30:11 <TrueBrain> in the setup {} blob
23:34:59 <blathijs> I think setup.py already has a custom cmdclass for something
23:35:04 <DorpsGek_III> [OpenTTD/nml] matthijskooijman commented on pull request #115: Fix #112: prevent __version__.py regeneration for source package https://git.io/Jf373
23:35:28 <blathijs> I posted another summary of what I think would be the best approach (assuming setuptools can do it, but TrueBrain suggestion sounds feasible)
23:35:34 <blathijs> Gotta run now though!
continue to next day ⏵
