IRC logs for #openttd on OFTC at 2009-08-16
⏴ go to previous day
00:00:04 <MyCatVerbs> Well. Building or renting a botnet is a little too illegal for my tastes. Probably more effective to put the URL up somewhere where a lot of angry people will see it. :P
00:04:52 <MyCatVerbs> OwenS: my thoughts exactly, but I didn't want to say it aloud, partly for fear of tempting fate. "Anonymous is not your personal army" and all that jazz.
00:05:26 <OwenS> I don't happen to hang anywhere near 4chan... but they do get things done :p
00:05:54 <xmakina> i hope you're using a very loose definition of "done"
00:06:33 <OwenS> xmakina: They do do things. Though they may not always be legal.
00:08:20 <xmakina> that's why i asked a very loose definition of "done" - they may do things but nothing ever gets "done"
00:08:51 <MyCatVerbs> I'm pretty sure some 4channers get done from time to time.
00:09:19 <MyCatVerbs> It would explain how their numbers always seem to be on the rise. Plainly, they must be multiplying.
00:09:26 <xmakina> lol - yes, they might be a bit more common :P
00:09:40 <xmakina> wait... define "done" - i was assuming you meant arrested
00:11:14 <MyCatVerbs> Well, occasionally it also involves handcuffs, but that's not all that common.
00:12:13 <OwenS> I'm reminded of the time they tracked down someone who posted a youtube video of him being cruel to his cat
00:12:58 <OwenS> ...The guy now has an Encyclopedia Dramatica page, recieved phonecalls from them 24/7, and got reported to the police
00:13:44 <Eddi|zuHause> i must hsve taken a wrong turn at albuquerque
00:14:03 <Eddi|zuHause> people i have never seen talk about stuff i have never heard
00:14:16 <OwenS> Incidentally, the first cartoon to contain that statement is no longer in circulation
00:56:54 *** KenjiE20|LT has joined #openttd
01:02:57 *** lobster has joined #openttd
01:14:57 *** DaleStan has joined #openttd
02:06:34 *** HerzogDeXtEr1 has joined #openttd
02:53:51 *** xmakina has joined #openttd
02:58:18 *** Rexxars has joined #openttd
03:12:56 *** TinoDidriksen has joined #openttd
03:43:19 *** TinoDidriksen has joined #openttd
03:50:17 *** xmakina is now known as xmakina|sleeping
04:15:57 *** xmakina|sleeping is now known as xmakina
04:31:43 *** reldred1 has joined #openttd
04:42:58 *** stuffcorpse has joined #openttd
05:32:13 *** welterde has joined #openttd
05:36:26 *** Singaporekid has joined #openttd
05:52:43 <R0b0t1> Hoped ya'll were prepared like the man said.
06:14:32 *** andythenorth has joined #openttd
06:29:25 *** Alberth has joined #openttd
06:45:46 *** ^spike^ has joined #openttd
06:56:38 *** pavel1269 has joined #openttd
07:28:12 <CIA-1> OpenTTD: alberth * r17198 /trunk/src/ (industry_gui.cpp lang/english.txt): -Fix [FS#2406]: Accept monthly production values in the scenario editor.
07:31:48 <CIA-1> OpenTTD: alberth * r17199 /trunk/src/ (news_gui.cpp news_type.h): -Codechange: Remove NF_VIEWPORT since it is implied by the news mode.
07:37:09 <Aali> (pointer type) == 0 does not give a warning with MSVC, (pointer type) == (something that has been #defined as 0) does
07:38:06 <Aali> hopefully I can kill the warning by switching off C++ mode
07:38:36 <Alberth> you should not compare integers with pointers
07:39:04 <Aali> I have a very good reason to
07:39:16 <Aali> and switching it into C mode made no difference.. figures
07:39:44 <Alberth> an enum is always an integer value, a literal "0" is either an integer *or* a NULL pointer.
07:40:35 <Alberth> so in the former, the compiler picks the NULL value, in the latter you don't give it that choice so it barks
07:40:40 <Aali> and it would be convenient if this would work in MSVC, but I can just aswell take out the 0 from that enum
08:13:33 <_ln> i would claim the literal 0 is always an integer.
08:19:44 <_ln> and comparing a pointer with an enum is wrong and has nothing to do with the literal 0.
08:21:33 <Alberth> _ln: I suggest you read the C++ manual where it is stated that 0 is also used as representation of the NULL pointer.
08:22:48 <TrueBrain> on some platforms you even need to define NULL as 0 ...
08:23:18 <_ln> Alberth: does that conflict with the claim that the 0 literal is always integer?
08:24:23 *** |Jeroen| has joined #openttd
08:24:58 <Alberth> _ln: together with the claim that comparing arbitrary integers with pointers is wrong, yes it does.
08:26:20 <Alberth> TrueBrain: it would be so much fun to make a C++ implementation that uses ~0 as NULL value :)
08:26:39 <TrueBrain> in C++ you can't, but isn't it one of the Cs that doesn't explicitly define it?
08:26:41 <_ln> comparing abitrary integers with pointers *is* wrong in C++.
08:27:06 *** andythenorth has joined #openttd
08:27:28 <Alberth> TrueBrain: yes, C++ does not say anything about the bit representation of NULL
08:28:36 <TrueBrain> Alberth: wasn't it C++ which does define that NULL should be 0? Can't remember .. either of those definitions failed to mention what NULL really is :p
08:29:03 <_ln> TrueBrain: (see my link above)
08:29:19 <TrueBrain> yes, I always trust random links given by random users :p
08:29:42 <Alberth> TrueBrain: yes, at user level it is 0, but afaik it is not defined at run-time
08:30:23 <_ln> TrueBrain: i'm not random, i'm constant.
08:30:42 <TrueBrain> Alberth: you got to love specifications :)
08:30:57 <Alberth> he also trusts random links given by constant users :)
08:31:18 *** Progman has joined #openttd
08:31:32 <Alberth> TrueBrain: yeah, I like having a solid foundation :)
08:31:33 <_ln> i understand that Stroustrup's C++ faq cannot be a reliable source of C++ information.
08:32:07 <Alberth> none the less, C++ surprised me this morning :(
08:34:27 <TrueBrain> it can still happen ;)
08:34:42 <R0b0t1> *cough*C++isevil*cough*
08:37:57 <Alberth> R0b0t1: yes, I would quit playing OpenTTD right now, if I were you.
08:38:11 <TrueBrain> I would burn your disks
08:38:15 <TrueBrain> just because it has C++ on it!
08:38:22 <R0b0t1> ;). I'm wearing my tinfoil hat. I'm safe from the evils of C++.
08:38:37 <R0b0t1> However, for you poor souls... I believe it is too late :(
08:38:51 <TrueBrain> AND I DONT CARE!!!MWHAHAHAHAHAHAHAHAHAHAHAHAHAA
08:41:54 <petern> yeah, since openttd switched to C++ the code has become totally unmanagable
08:43:22 *** LordAzamath has joined #openttd
08:43:54 *** Cybertinus has joined #openttd
08:44:00 <_ln> wasn't it TrueBrain who hated C++ and said he would stop working with OTTD if it was switched to C++?
08:45:14 <petern> TrueBrain always stops working on ottd
08:45:32 <TrueBrain> I have for a long time now
08:57:43 *** oskari89 has joined #openttd
09:00:09 <CIA-1> OpenTTD: alberth * r17200 /trunk/src/news_gui.cpp: -Codechange: Initialize NewsWindow::duration, add some documentation strings.
09:04:27 <_ln> Alberth: so is it an integer?
09:05:05 <CIA-1> OpenTTD: rubidium * r17201 /trunk/src/ai/api/ai_road.hpp: -Fix [NoAI]: don't say you're building a depot when you're actually building a station (API docs typo)
09:08:51 <Alberth> is 'long x; char *p; p == (x - x)' comparison with an arbitrary integer?
09:10:44 *** frosch123 has joined #openttd
09:11:04 <Alberth> hmm, even 'char x' would be ok due to C++ widening. I don't think size_t would be needed, as comparing with integer 0 is ok
09:11:52 <_ln> by 'widening' do you mean 'integer promotion'?
09:12:06 <TrueBrain> Alberth: you are absolutely right
09:12:11 <TrueBrain> all are accepted by C!
09:12:17 <Alberth> ie the question is, is "0" less arbitrary than some expression that happens to result in a 0 value.
09:13:10 <_ln> 0 is not arbitrary, it is 0. expressions whose value is determined at runtime are arbitrary.
09:13:15 <Alberth> TrueBrain: C is much more forgiving in mxing integers and pointers, in general.
09:13:20 <TrueBrain> Alberth: strangly enough, with -O0, the 'x - x' part is done in asm
09:14:52 <Alberth> _ln: "expressions whose value is determined at runtime are arbitrary." <-- so if I have a really smart compiler, I am allowed to write this down? Nice language definition :)
09:15:29 <Alberth> TrueBrain: you do use -Wall ?
09:15:36 <TrueBrain> besides in C++ it is an error
09:15:49 <_ln> the nature of expressions does not depend on any compiler.
09:16:25 <TrueBrain> hmm, I read it wrong, it doesn't substract x from x .. it substracts with no clear reason :p
09:16:38 <TrueBrain> but okay .. x * 0 works too, which suprised me :p
09:17:06 <Alberth> TrueBrain: it is really 'disable optimizations' :)
09:18:17 <TrueBrain> p == (x - y), with x and y being constants of 1 :p
09:19:09 <TrueBrain> I think GCC is stupid regarding this .. special casing it .. and doing optimizations while you tell him not to :p
09:20:37 <CIA-1> OpenTTD: alberth * r17202 /trunk/src/news_gui.cpp: -Codechange: News item is already given as argument.
09:22:40 <TrueBrain> define p as NULL, sorry
09:23:52 <Alberth> it may or may not, depending on the actual storage of y
09:23:55 <TrueBrain> in other words: it always compares to 0
09:24:02 <TrueBrain> it never really compares it to y
09:24:49 <TrueBrain> so I think I just showed that 0 == 1 :)
09:25:27 <Alberth> that's allowed. const values are not guaranteed to change when assigned.
09:26:33 <TrueBrain> of course I shouldn't be changing the value of a const .. but I compile this with -O0 .. I don't expect any optimizations to be done ...
09:27:00 <TrueBrain> but g++ refuses to do a compare between integers and pointers .. and if it thinks the value is 0 ...
09:38:21 <LordAzamath> is there an OpenTTD Steam Community?
09:38:51 <TrueBrain> what would Steam want to do with Open Source stuff?
09:39:05 <LordAzamath> no, I mean a steam community
09:39:31 <LordAzamath> I'm pretty sure at least 60% here have Steam
09:39:31 <TrueBrain> haha, sorry, I assumed Valve Steam :p
09:39:32 <_ln> but steam is obsoleted by diesel and electricity
09:40:17 <LordAzamath> well I was just wondering
09:40:25 <LordAzamath> I guess there isn't then
09:40:30 <TrueBrain> LordAzamath: I never read any talk about it
09:40:52 <TrueBrain> although you are not the firs tto link Steam to OpenTTD .. there once was a person who thought we should publish our game over Steam, because that would be much more easier or whatever
09:41:20 <Alberth> LordAzamath: maybe with TTDP, since that is older
09:41:23 <TrueBrain> but there are 2 communities :)
09:41:23 <LordAzamath> lol there actually is a community called openttd
09:41:34 <TrueBrain> the other at least as 11 :p
09:42:30 <TrueBrain> so I guess there you do have your answer :) LordAzamath: I also wouldn't see a reason to start a community there I guess :p
09:43:31 <TrueBrain> btw, 60% is a big assumption :p
09:51:34 <LordAzamath> TrueBrain you have Steam account?
09:52:39 <TrueBrain> client installed: no
09:53:38 <LordAzamath> well out of us two, 100% have a steam account :D
09:55:52 <TrueBrain> you have to be excellent in math :)
09:58:50 <Alberth> TrueBrain: has already shown that 0 == 1, so no problems expected here :)
09:59:18 <LordAzamath> and how exactly is that so?
10:00:44 <R0b0t1> Steam has some cool games, pity I can't get them to work.
10:01:03 <R0b0t1> Wine runs the ones I want but my driver and card make them fail after about an hour or less :(
10:06:46 *** ^spike^ is now known as ^Spike^
10:18:44 * frosch123 is redirected to tb
10:20:49 <frosch123> (except it really contains something interesting)
10:21:24 *** Nickman87 has joined #openttd
10:22:56 <TrueBrain> frosch123: it tells me my user doens't exist :p
10:23:29 <frosch123> your user? try truelight :)
10:24:52 <frosch123> even opera cannot open it :p
10:25:02 <TrueBrain> frosch123: ah, good one :)
10:25:11 <petern> takes me to É€²éšŽä¿¡è™Ÿé…?置法(zh-TW)
10:25:26 <TrueBrain> it tells me there is no text on that page
10:26:09 <frosch123> but did you reach 進階信號�?置法, or only the other one?
10:26:16 <petern> the link appears to be not utf-8
10:26:55 <petern> going directly it says bad title
10:27:30 <TrueBrain> given that most db tables are in latin1
10:27:33 <TrueBrain> it isn't a real suprise I guess
10:30:43 <petern> so... database -> manually delee
10:33:32 *** Default_ has joined #openttd
10:33:46 <petern> what encoding is on the page? :s
10:33:49 <CIA-1> OpenTTD: yexo * r17203 /trunk/src/ai/api/ (ai_road.cpp ai_road.hpp): -Change [NoAI]: Add IsRoadTypeAvailable(GetCurrentRoadType()) as precondition for several AIRoad::* functions
10:39:19 *** KenjiE20 has joined #openttd
10:40:08 *** BaronChaos has joined #openttd
10:40:23 *** ChanServ sets mode: +v tokai
10:41:55 <andythenorth> I just invented a new game variation....instead of choosing vehicles in the purchase window, you have only one or two options: build vehicle (or build engine, build wagon for trains).
10:41:56 <andythenorth> When you buy, the game builds a vehicle at random from a list. Then you have to figure out how best to make use of it....
10:42:22 <andythenorth> I haven't coded it :|
10:44:19 <petern> youjust hyou can do that with newgrf ;)
10:44:25 <petern> you can do that with newgrf ;)
10:44:56 <BaronChaos> how do you prevent people from building lots of vehicles, selling the ones they dont need?
10:46:47 <BaronChaos> an idea could be setting the selling price to zero
10:51:22 <planetmaker> BaronChaos: and what would that help?
10:52:17 <planetmaker> and what would you tell those people who say "oh, damn, just bought the wrong engine"?
10:52:25 <planetmaker> especially in the initial game phase?
10:53:08 *** bushwacker has joined #openttd
10:53:09 *** bushwacker has left #openttd
10:53:33 <Yexo> planetmaker: it was a reaction on andythenorths idea
10:53:50 <andythenorth> planetmaker: I think in this case there'd be no such thing as 'the wrong engine' ;)
10:54:04 <planetmaker> Yexo: oh... that indeed might be true :-)
10:54:19 <andythenorth> I don't know what the emoticon for "I'm being silly" is, but we could use one around here...
10:55:16 <Alberth> a ':' followed by a 'p' normally
10:55:19 <planetmaker> andythenorth: sure enought it could even be done manually by means of a dice :-)
10:55:28 <andythenorth> I do think my 'invention' might be...intriguing for a coop game
10:56:07 <planetmaker> uh... it would be completely different from what is played usually on our servers
10:56:30 <welshdragon> some would call it 'unique'
10:56:59 <welshdragon> others wou;d call it 'a royal pain in the arse\
10:57:40 <R0b0t1> Ah, you mean, prevent that, ehm, thing that AI uses?
10:57:46 <R0b0t1> The extremely insidious one.
10:58:01 <andythenorth> another one for our fine fleet of acronyms
10:58:54 <andythenorth> There could be a vehicle that costs a ridiculous amount to run as soon as you buy it, thereby instantly solving the 'too much money' problem
11:07:17 <frosch123> andythenorth: btw. did you set power and te only for the front vehicle, or also for articulated parts?
11:07:54 <andythenorth> frosch123: you're talking about HEQS?
11:08:45 <frosch123> the point is, that for trains power and te and weight is only valid for the first articulated part of engines and wagons
11:08:57 <frosch123> while the rv patch on the forums does different
11:09:19 <frosch123> independent of what would be better, it is inconsistent
11:09:53 <Sacro> Q: Why don't jokes work in octal?
11:10:53 <BaronChaos> planetmaker: yeah i was talking to andy
11:11:22 <andythenorth> frosch123: I have one vehicle where TE / power is set for articulated part. The rest are on lead vehicle only.
11:11:52 <andythenorth> I would be happy with either way, as long as it's consistent and documented
11:12:48 <Sacro> [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
11:15:22 <BaronChaos> unix russian roulette?
11:16:16 <_ln> Sacro: *Click* should be in quotes.
11:17:16 <BaronChaos> and only a problem if there are ...Click... files in your folder
11:18:28 <_ln> BaronChaos: what kind of a revolver suddenly lists some files
11:19:07 <BaronChaos> a damaged electronic one?
11:20:37 *** LordAzamath has joined #openttd
11:20:40 <BaronChaos> what kind of a revolver suddenly deletes only the files you are allowed to? ;-)
11:22:13 <BaronChaos> then your bullet only kills wenn you have sudo rights ;-)
11:22:28 <TrueBrain> Yexo: Dustin completely failed to follow 'coding style' for his own changes :p
11:23:30 <Yexo> wasn't that what I told yesterday?
11:23:38 <TrueBrain> but you didn't update it?
11:24:10 <Yexo> problem is, a few of his changes were correct
11:24:16 <TrueBrain> I was talking about SQ_pitfalls btw
11:24:51 <Yexo> ha, he's not even consistent there
11:25:18 <TrueBrain> and // comments on a single line :p
11:26:05 *** TheMask96 has joined #openttd
11:30:19 <SmatZ> what are you talking about?
11:30:41 <Yexo> wiki edits by dustin not following coding stle
11:31:05 <TrueBrain> while he bitched in a few changes about coding style and blabla :p
11:32:59 <Tefad> er new kezbrd.. is while(..) \n { not approved?
11:33:44 <Tefad> grawr at GIANT L shaped enter keys.
11:34:41 <Yexo> Tefad: there is nothing wrong with that, but it's not the openttd coding stle
11:35:23 <Tefad> Yexo: we're in context of this channel.. so yes
11:35:31 <Tefad> that is incorrect style
11:35:38 <Tefad> (according to you, now)
11:36:03 <Tefad> i guess it's good i've never bothered to look at openttd's source
11:36:07 <Tefad> i think i'd have nightmares
11:36:38 <TrueBrain> are you so carried away by our coding style
11:36:55 <Tefad> crap was ripped out of dos machinecode->C conversion wasn't it?
11:37:15 <Tefad> dunno. i've never coded in a project other than my own
11:37:19 <TrueBrain> crap goes in the toilet
11:37:36 <Tefad> i'd probably go totally OCD on code that doesn't fit my style
11:38:09 <Tefad> to me, { not on first character of line are distracting and makes code harder to read/follow
11:38:52 <Tefad> exceptions for struct, array init if it is short
11:39:43 <TrueBrain> and so we have all our own preference .. hence a coding style! :)
11:40:34 <Tefad> yes, but i am the only correct one, of course.. you see
11:41:35 <TrueBrain> yeah, sorry, that is completely my mistake :)
11:52:31 <SmatZ> [13:30:41] <Yexo> wiki edits by dustin not following coding stle <== ah, thanks :)
12:09:54 *** Terkhen has joined #openttd
12:35:52 *** andythenorth has joined #openttd
12:53:53 <andythenorth> frosch123: could cb 36 be extended for RVs to cover hp, TE, weight etc?
13:05:38 <frosch123> isn't that a question for Terkhen?
13:11:54 <Terkhen> I think that it is a question for me, too
13:12:59 <Terkhen> but since I never checked callbacks code, I don't know how it could be done
13:13:34 <frosch123> see GetEngineProperty and GetVehicleProperty
13:14:00 <Terkhen> it can get done once the rv patch is more developed, as it has more urgent goals to complete before that
13:14:12 <frosch123> but esp. for articulated vehicle you will very quickly run into the same problems as for capacity, refittability, ...
13:16:59 <frosch123> so likely it is a lot less troublesome to only allow it for the front part
13:20:02 <Terkhen> I will add callbacks to the todo list... I still have a lot of things to get working before, though
13:21:40 <Ammler> Terkhen: daylenght2grf conversion?
13:24:37 <Terkhen> Ammler: I finally implemented a new NewGRF property for long format model life
13:25:45 <Terkhen> I only made two example GRFs, but it would not be difficult to extend it for all other vehicles / houses, etc
13:29:07 <Terkhen> it was the better option to create it without having to duplicate vehicles
13:30:03 *** fonsinchen has joined #openttd
13:33:14 <Ammler> Terkhen: the big issue with your conversion is the support for other newgrfs, as newgrfs are mostly the reason for daylength patch.
13:34:50 <Terkhen> that's why I stopped the millenium conversion set
13:35:05 <Terkhen> it was impossible to give support for other newgrfs without a longer model life
13:36:33 <Terkhen> once it is implemented, to give them support it only needs to change the long format introduction date and long format model life values of all vehicles of the NewGRF according to a parameter
13:40:47 *** KritiK_ has joined #openttd
13:44:57 *** KritiK_ is now known as KritiK
13:48:40 *** Coco-Banana-Man has joined #openttd
13:59:35 *** Elton01330 has joined #openttd
14:49:20 *** Biolunar has joined #openttd
15:09:33 <petern> at least it was a freight train
15:46:34 *** Polygon has joined #openttd
16:06:18 <CIA-1> OpenTTD: alberth * r17204 /trunk/src/news_gui.cpp: -Codechange: Move viewport initialization into the constructor of the news item window.
16:21:29 *** oskari89 has joined #openttd
16:23:30 *** andythenorth has joined #openttd
16:36:14 *** fonsinchen has joined #openttd
16:49:11 <CIA-1> OpenTTD: alberth * r17205 /trunk/src/genworld_gui.cpp: -Fix (r17175): Make year and snow line up/down buttons raise again.
17:33:23 <fonsinchen> In LoadUnloadVehicle there is a special case where a train can reverse in a station. Then VF_LOADING_FINISHED is set in its vehicle flags to make it leave the station. So there could be a possibility that LoadUnloadVehicle is called with a loading order but unload_time_rem == 0. This would trigger an assertion in LoadUnloadVehicle, provided that Vehicle::HandleLoading is not called in between. This, however can happen as TrainLocoHandler can return
17:39:35 <fonsinchen> It could have to do with a train reversing and then immediately breaking down in a station.
17:40:07 *** KenjiE20 has joined #openttd
17:45:14 *** Progman has joined #openttd
17:45:59 <CIA-1> OpenTTD: translators * r17206 /trunk/src/lang/ (11 files): (log message trimmed)
17:45:59 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
17:45:59 <CIA-1> OpenTTD: catalan - 1 changes by arnaullv
17:45:59 <CIA-1> OpenTTD: simplified_chinese - 6 changes by Gavin
17:45:59 <CIA-1> OpenTTD: dutch - 5 changes by Bart
17:46:01 <CIA-1> OpenTTD: finnish - 2 changes by jpx_
17:46:01 <CIA-1> OpenTTD: french - 3 changes by glx
17:48:17 *** KritiK_ has joined #openttd
17:53:57 *** KritiK_ is now known as KritiK
18:18:41 *** Audigex has joined #openttd
18:31:25 * Alberth brings a fresh bag of h's.
18:32:13 * frosch123 empties it in one go, mhwhahahahahahahahahahaha
18:36:18 * frosch123 blinks at ttdp r2180
18:37:08 <DaleStan> You didn't know that already?
18:38:05 <frosch123> well, he keeps on bursting into new levels
18:43:44 <glx> that's crazy, it's hard enough to do it in C
18:44:40 <petern> it is a somewhat large file
18:46:53 *** Audigex has joined #openttd
18:56:26 <fonsinchen> can I get a link of cargodest in asm?
18:57:40 <DaleStan> Yes and no. Most of it is there, but the definitions of some necessary symbolic constants didn't get committed.
18:58:48 <DaleStan> So you can read it, but it won't assemble without some work.
18:58:59 <Ammler> DaleStan: would it be possible to redirect the nfo warnings to stderr like you did with grfcodec?
18:59:55 <Ammler> hmm, did I already ask in tt-forums thread?
19:00:33 <DaleStan> If you send the NFO in on stdin, it'll come back processed on stdout and everything else goes to stderr. Otherwise, some things go to stdout and some to stderr, for reasons I don't recall now.
19:01:40 <Ammler> well, I run renum a.nfo 1>log 2>error, some warnings are still in log
19:02:25 <Ammler> so you see in error, there was something wrong, but you have to look in log to see what.
19:05:11 *** KenjiE20 has joined #openttd
19:11:48 * TrueBrain looks under Ammler skirt .. ieuw .. stinks
19:12:57 <DaleStan> Ammler: Can you give me an NFO that demonstrates that? And/or which messages you think are in the wrong place?
19:15:32 <Ammler> make: [was.rnfo] Error 3 (ignored) in error log
19:15:54 <TrueBrain> glx: I agree with you: it is crazy
19:27:37 <fonsinchen> It does look interesting. The patch is rather small for such a complex feature. They also seem to have load balancing right from the start and they have a TTL on cargo packets to prevent infinite circling.
19:28:12 <TrueBrain> and once again TTDp beats OpenTTD :p (with going into trunk :p)
19:30:53 <fonsinchen> Well, the openTTD devs wouldn't have accepted that code. It's practically undocumented and contains lots of commented out code.
19:31:24 <frosch123> well, if it does not assemble, there is a chance. TrueBrain! Go, go, go!
19:31:49 <TrueBrain> let me think about that for a second ......
19:32:16 <TrueBrain> oh, yes, it is going to be legend
19:32:30 <Xaroth> besides, frosch123, TB is busy on a better project :P
19:35:02 <TrueBrain> I wonder if Ammler is suprised Xaroth knows that word, of that there is anything better than OpenTTD .. hmm :p
19:35:45 * frosch123 was mainly wondering about the "on" part
19:36:44 <TrueBrain> everyone is a critic!
19:36:59 <Xaroth> TrueBrain: that's because they fail to see the awesome
19:37:15 <TrueBrain> so we should suit up!
19:37:31 <DaleStan> <fonsinchen> Well, [it] contains lots of commented out code. <-- I don't understood that fascination either. We have version control for a reason.
19:38:00 *** KenjiE20 is now known as Guest229
19:38:04 *** KenjiE20 has joined #openttd
19:38:23 <DaleStan> This pair of lines is especially mind-boggling:
19:38:24 <DaleStan> / dd canhavecargodest
19:38:40 <DaleStan> *// dd canhavecargodest
19:39:00 *** welshdragon is now known as BobXP
19:39:16 *** BobXP was kicked by DorpsGek (We hate XP)
19:40:29 <fonsinchen> I can't seem to reproduce the problem with load_unload_time_rem == 0 triggering the assertion in LoadUnloadVehicle. But I believe the guy who posted it that it's somehow possible to create that situation. I would preemptively fix it by setting load_unload_time_rem to 1 in LoadUnloadVehicle if the train has reversed.
19:40:45 *** BobXP is now known as Welshdragon
19:41:03 <fonsinchen> DaleStan, obviously you are less strict about coding style ... which has benefits and drawbacks.
19:41:29 <frosch123> :o "preemptively" and "fix" in one sentence
19:41:39 *** Welshdragon is now known as welshdragon
19:42:36 <fonsinchen> "preemptive" is probably the wrong word, but I guess you got the meaning.
19:43:19 <TrueBrain> even a preventive fix is weird :p
19:43:53 <TrueBrain> but we all understand what he means :p
19:44:19 <frosch123> is there a difference between preemptive and preventive ?
19:44:40 <TrueBrain> is a condom preemptive?
19:45:00 <glx> there's some "cooperation" in preemptive IIRC
19:45:08 <fonsinchen> It means I don't konw the exact code path to that assertion. But I'd fix the only place where load_unload_time_remaining can be left at 0 without the order type being changed from OT_LOADING.
19:46:25 <TrueBrain> " To appropriate, seize, or take for oneself before others." <- preempt :p
19:50:13 <pavel1269> today, i really look like sameone who comes from southern states :P ... great time at pool .... hope you were also at pool at your place ;-)
19:50:32 <TrueBrain> I did beter: I want indoor rockclimbing :)
19:51:39 <andythenorth> I went indoor rock climbing too. hence tired fingers. and blisters (flappers!)
19:52:24 <Eddi|zuHause> oh, then you should have met each other :p
20:00:02 <ed__> anyone know what happened to openttdcoop?
20:00:55 <ed__> are they moving websites or something?
20:00:58 <frosch123> ask in #openttdcoop
20:03:39 <planetmaker> replace .org by .ammler.ch
20:05:35 <ed__> thanks. couldn't find the irc channel info for them
20:06:12 <frosch123> that's easy, just type !password
20:09:52 <Prof_Frink> SmatZ: Y'what, eh?
20:13:13 *** HerzogDeXtEr has joined #openttd
20:14:21 *** Chruker has joined #openttd
20:15:04 *** Zuu was kicked by DorpsGek (Wrong channel. Retry in #openttdcoop.)
20:32:17 <Zuu> Woo, Canada-line (the new skytrain line in Vancouver) opens Early so I'll be able to try it out before I have to go home :-)
20:56:52 *** LordAzamath has joined #openttd
21:01:22 *** ChanServ sets mode: +v tokai
21:33:25 *** Cybertinus has joined #openttd
21:44:44 *** Cybert1nus has joined #openttd
21:49:08 *** Cybertinus has joined #openttd
21:58:15 * OwenS keeps forgetting operator is a C++ keyword...
22:02:19 * DaleStan prefers op or oper for that variable name.
22:02:47 <OwenS> I'm currently using opCode normally (because it's the operator's number I'm refering to)
22:06:43 <OwenS> Hmm... Do I reserve all names beginning with __ or which begin and end with it? Hmm
22:19:35 <Spoons> 16/23:19:29 < nolyc> Section 17.4.3.1 of the C++ standard reserves any name which contains two consecutive underscores, which begins with an underscore followed by an uppercase letter or begins with an underscore and is in the global namespace.
22:20:50 *** Spoons is now known as FauxFaux
22:27:21 <MyCatVerbs> OwenS: reserve with prefixed __s then. Better to be consistent with other languages. :)
22:27:38 <MyCatVerbs> (I thought the C standard reserved the double underscore prefix too?)
22:29:37 *** ^Spike^ is now known as ^spike^
22:30:02 <OwenS> I was considering the python __reserved__ route; partially since when designing my language, so far, when in doubt about something on which Python and C++ differ, I've done things the Python way :p
22:30:43 <FauxFaux> Python and C++. Oh dear.
22:31:48 <Tefad> python. bleh. unless its being run through a proper VM
22:31:51 <OwenS> Python and C++ are two of my prefered languages. That doesn't mean they're my ownly source of inspiration; an important third one is JavaScript (Or rather ECMAScript, not the mess that is browser JavaScript :P )
22:32:12 <Tefad> fresh cookies warmed in owen.
22:33:36 <OwenS> def hello(name) print("Hello, " + name + "!"); would be a simple hello world function :p
22:37:11 <MyCatVerbs> Tefad: define "proper VM"?
22:37:41 <MyCatVerbs> Tefad: I'm led to understand that jython and ironpython aren't actually faster than cpython on real (i.e. large and fugly) codebases.
22:38:15 <OwenS> MyCatVerbs: They are faster under high loads in most cases from what I've read
22:38:32 <OwenS> Jython scales best, but is also the slowest for low loads
22:40:34 <MyCatVerbs> I thought that was on thread-heavy microbenchmarks, mainly?
22:40:47 <MyCatVerbs> Stuff that tends to exercise the bits of CPython that suck hardest.
22:41:10 <MyCatVerbs> I could be wrong, I haven't looked into it well enough to say for certain.
22:41:48 <OwenS> I've seen it on a parser which generates thousands of an objects (They were building a compiler for the CLR, and benchmarked the parser accross CPython/Jython/IronPython)
22:42:23 <MyCatVerbs> Oh, neat stuff. ^^
22:43:20 <OwenS> My language targets LLVM (for great native code generation), maybe soon it's own VM, and maybe libJIT
22:45:36 <Tefad> all i know is interpreted python is balls slow and that makes me not want to use it.
22:46:01 <MyCatVerbs> Why bother with more than one target if one of your targets is LLVM?
22:46:47 <MyCatVerbs> Those are good reasons, but I'm also curious as to what OwenS's reasons are. ;)
22:47:07 <OwenS> MyCatVerbs: The VM is a backup for when LLVM is unavailable. libJIT is so I can benchmark it on both - and learn both :P
22:47:56 <OwenS> I'm currently in the process of refactroing my codegen
22:48:03 <OwenS> Mainly to get it all out of the AST :p
22:48:34 <OwenS> It's getting refactorted into a generic interface (As is the tree pretty printer)
22:48:38 *** reldred1 has joined #openttd
22:52:29 <OwenS> Once the codegen is out int it's own class it's getting a major overhaul to add coroutine supprot
22:53:48 <OwenS> Which does have the unfortunate implication that all function calls involve a malloc... (or rather a vmheapalloc, since I use a custom heap :P)
22:54:44 <MyCatVerbs> How unfortunate that might be depends on your memory allocator.
22:55:13 <OwenS> It's not that bad considering I don't need to worry about freeing blocks (I'm using a compacting GC... so thats handled for me :P )
22:55:42 <OwenS> So an alloc is little more than adding to the heap position :p
22:56:07 <MyCatVerbs> I would hardly count that as handled *for* you. You had to write the compacting GC too, didn't you? ;)
22:56:25 <OwenS> Yes, but I needed to anyway with my design :p
22:56:52 <MyCatVerbs> So you have about the same allocator overhead as every other competently GC'd language on the planet then - one integer increment and range check on the fast path, arrrrgh bees and scorpions on the slow path.
22:57:35 <OwenS> And an arrrrrgh molten lava on the really slow (Heap's full... enlarge if the application permits)
22:57:37 <MyCatVerbs> I think you can actually improve on that if you use something like libsigsegv. :)
22:58:11 <OwenS> I don't fancy trying to move a structure which has yet to get it's type information down :p
22:59:14 <MyCatVerbs> I was thinking, Cheney on the MTA, with just a pointer increment on the fast path - no range check. Handle the range check by segfaulting when you reach the end of the nursery. :)
22:59:49 <OwenS> Yeah, N page VM arena followed by a guard page would work
23:00:45 <OwenS> And implementing signal handlers isn't really an issue when I already need them for divison by zero handling :p
23:01:09 <MyCatVerbs> I wonder whether that would be faster than increment and range check? Since branch prediction would probably completely flatten the range check anyway.
23:01:45 <OwenS> I'm not sure about it completely flattening it when there are several thousands of them distributed throughout the generated code :p
23:02:06 <MyCatVerbs> Oh yeah, I forgot that. >>
23:02:40 <OwenS> But adding support for that kind of stuff isn't bad when you already need OS specific support code anyway
23:03:48 * MyCatVerbs has a sneaky feeling that guard page trickery would probably end up involving abuse of MAP_FIXED in at least two places.
23:04:23 <OwenS> mprotect(guard_addr, 4096, PROT_NONE);
23:06:24 <MyCatVerbs> But how do you get the code that triggered the page fault to complete the write, and then funcall the GC?
23:07:46 <MyCatVerbs> I bet the simplest thing would be to mprotect(guard_addr, 4096, PROT_READ|PROT_WRITE) and then mmap(guard+4096,size,PROT_READ|PROT_WRITE,MAP_FIXED|MAP_ANON,-1,0) to enlarge the arena without ever changing its address.
23:08:37 <MyCatVerbs> Or you could just set a flag that says "hai thar, plz branch to gc kthxbai", and then the allocation routine is "pointer increment, then check this flag". But that's not an improvement on "pointer increment, then range check".
23:08:38 <OwenS> The issue is that allocation failure should trigger a compaction...
23:09:44 <OwenS> All allocations involve first storing a "resume address" in a memory location?
23:09:58 <MyCatVerbs> You require that memory is always written to immediately upon allocation, and also that every allocation has a couple NOPs after it. Then your signal handler overwrites the NOPs with a stub that calls the GC. Bonza! :D
23:10:09 <MyCatVerbs> ...I like your suggestion better. =D
23:10:28 <OwenS> Yeah, since LLVM doesn't allow yours :p
23:11:09 <Eddi|zuHause> > svn co svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/kaffeine
23:11:10 <Eddi|zuHause> svn: No such revision 1012147
23:11:36 <OwenS> MyCatVerbs: ...This makes all allocations drop everything on the floor (Or rather stack frame) though... I may have just moved the bees to the "fast" path :p
23:12:36 <OwenS> Hmm... It could chuck out a different retry address though :p
23:12:58 <MyCatVerbs> OwenS: ooh, howsabout this crap idea:
23:13:42 <MyCatVerbs> Wait, no, that would be dumb. NVM.
23:14:07 <OwenS> Compaction is gonna be fun though. I'm gonna have to move the stack frames I'm updating...
23:14:59 <MyCatVerbs> Keep one pointer to the highest allocated space, one to the highest allocated space that is considered "committed", and a retry address.
23:15:53 <MyCatVerbs> Then, for pure computations that it's safe to blow up and retry again from scratch, you only need to set the retry address once, and set the "committed" address after making (and writing to) the *final* allocation. :)
23:16:54 <OwenS> Hmm... All in all, it may be easier (and more optimizer friendly) to just go with the range check :p
23:17:28 <MyCatVerbs> Yeah, I'd go with the range check. :)
23:17:46 <MyCatVerbs> I'm just wondering what you could do to improve on it.
23:20:39 <OwenS> My GC is gonna be loads of fun :p
23:27:19 <SpComb> speaking of python, I tried out Cython for the first time this weekend
23:29:35 <Eddi|zuHause> hm.. what's the difference between "Factory" and "Unstable" repositories?
23:29:51 <OwenS> Isn't that an OpenSuSE thing? :p
23:31:20 <SpComb> 787 lines of .pxd, 1410 .pyx... 25811 lines of .c
23:31:44 <OwenS> I'd presume factory means going in next release, unstable means may not be in next release
23:32:15 <SpComb> although that's with -g
23:32:59 <SpComb> although it doesn't seem to matter
23:33:12 *** Eddi|zuHause has joined #openttd
23:33:21 <SpComb> but Cython's a curious language
23:33:29 <SpComb> it's odd, but it mostly works
23:33:44 <SpComb> worst bit so far was trying to hack the cimport module system to work with python packages
23:37:58 <OwenS> My string format's gonna be funky
23:38:40 <OwenS> Well, actually, in context with the rest of the heap... no... just a null terminated UTF-16 string (With a size at the front to make heap walking easier :P)
23:41:50 <OwenS> Doing lots of string ops will cause lots of copies though...
23:44:24 * SpComb plays with his PyObjects
23:44:46 <SpComb> had to do some funky stuff to make _PyString_Resize work
23:45:08 <SpComb> normally, python strings are immutable... with one exception... _PyString_Resize can truncate strings with a refcount of 1
23:45:22 <SpComb> but that doesn't work at all with Cython's syntax or semnatics
23:45:38 <SpComb> trick was to stick to pure PyObject*'s and then a bit of try-finally
23:46:01 <OwenS> In my language I don't know how many references a string has so it always has to be copied
23:46:13 <OwenS> If you want it to be faster... use a Rope :p
23:46:27 <SpComb> immutable strings aren't a bad thing
23:46:38 <SpComb> ...as long as you also provide some kind of mutable byte array
23:46:46 <SpComb> which, python < 2.6, does not
23:48:29 <OwenS> Mutable byte array? I don't ATM, but the standard library will be having a ByteArray :p
continue to next day ⏵