IRC logs for #opendune on OFTC at 2009-10-07
⏴ go to previous day
02:00:03 *** Xaroth_ has joined #openDune
07:27:04 <Xaroth_> my connection survived!
07:28:25 <Xaroth_> now hopefully it won't be a total bastard today, and they'll fix it early tomorrow...
07:29:50 <Xaroth_> TrueBrain: health or hitpoints? << Hitpoints tbh
07:34:25 <Xaroth_> hm, we should try to find an easy way (for users) to find the exact version (revision) they are running so bugreports actually remain sane.
08:13:28 <TrueBrain> "When you play with fire, there is a 50/50 chance something will go wrong, and nine times out of ten it doesn"
08:13:33 <TrueBrain> late for class, be back later :)
08:20:28 <Xaroth_> TrueBrain: making a post on the private forum with a draft for release information
08:20:41 <Xaroth_> like, cycle, version string explanation/scheme
08:33:45 <TrueBrain> k, not going to classes
08:40:53 <TrueBrain> so what to do today? Not that I have that much time, but: more playing, more converting, or shall I by now upgrade the tool to be better?
08:40:59 <TrueBrain> (as in, make better decompiled code)
08:42:28 <Xaroth_> well if you tell me how to get my install ready to decompile later today (read: around 9-10ish tonight) I can also help with the whole playing part
08:42:51 <TrueBrain> for the playing part you need the JIT
08:42:57 <TrueBrain> is only closely related to the decompiler
08:43:06 <TrueBrain> (it uses a single component from it :))
08:43:27 <Xaroth_> I'd personally lean towards getting better decompiled code, but that all depends on what kind of improved decompiled code
08:47:17 <TrueBrain> okay, I have been thinking about that
08:47:25 <TrueBrain> I need to do some restructring
08:47:36 <TrueBrain> but I think I add an option where you say: this is a borland C project
08:47:49 <TrueBrain> and that it can do even more cool things ..
08:52:28 <TrueBrain> k ... say I would start a nightly build from today on, that would be 0.0.0.<revision. After 0.1 release that would be 0.1.0.<revision>, or what?
08:54:26 <TrueBrain> missing dots at the end of lines, rest looks good. X1 = 3, X2 = 2
09:08:13 <Xaroth_> nightlies should be full versions, 0.1.0.revision
09:08:29 <Xaroth_> that way version comparing should be much easier than with, f'ex ottd
09:09:03 <Xaroth_> get the first part of the version, split it on the dots, compare the numbers left to right, and you'll know if your version is newer or older than the other
09:09:27 <TrueBrain> aren't OpenTTD nightlies like 0.7.99.<revision>
09:09:30 <TrueBrain> which once will be 0.8?
09:09:43 <Xaroth_> no, nightlies are r<revision>
09:09:55 <Xaroth_> no further version info
09:10:06 <Xaroth_> well, on the file itself
09:10:36 <TrueBrain> 0.8.0.revision in fact
09:10:52 <Xaroth_> though the client announces itself as r<revision>
09:10:59 <TrueBrain> and r<revision> is only used in network and GUI
09:11:06 <TrueBrain> internal there is a new version string
09:11:34 <TrueBrain> also 0.8.0.<revision> there
09:11:38 <Xaroth_> I don't see why you should be using multiple different version strings to begin with :/
09:12:02 <TrueBrain> when I wrote the network, there wasn't a newgrf-version-string
09:12:14 <TrueBrain> when it was created in its current form, the person had no knowledge of network, and it was not ported to there
09:12:17 <TrueBrain> in result, 2 systems
09:12:20 <Xaroth_> luckily we can avoid all that :)
09:12:34 <TrueBrain> either way .. 0.1.0.<revision> goes to 0.1, or is passed 0.1?
09:12:59 <TrueBrain> so we now are version 0.0.0.174
09:13:10 <TrueBrain> and at 1nov we are 0.1.0.<bigger number>
09:13:30 <Xaroth_> once we release it we start with 0.1 (0.1.0.0 for calculating means), and nightlies at 0.1.0.r
09:13:45 <Xaroth_> that way if you compare them, the nightly is always newer than it's parent release
09:14:04 <TrueBrain> k ... when releasing 0.1, it is wise to branch such version
09:14:15 <TrueBrain> as trunk will go on with main development, and a branch can be used for simplistic fixes
09:14:21 <TrueBrain> (well, for 0.1 that would be stupid, but okay)
09:14:29 <TrueBrain> now the whole 'easy comarping of revisions' falls :p
09:14:59 <TrueBrain> as both the branch as the trunk get 0.1.0.<revision>
09:15:18 <Xaroth_> hence why official releases don't carry their revision :)
09:15:22 <Xaroth_> as such, are counted as 0
09:15:35 <TrueBrain> what have official releases have to do with it?
09:15:44 <TrueBrain> branch/0.1 -> revision 0.1.0.341
09:15:48 <TrueBrain> trunk -> revision 0.1.0.340
09:15:59 <TrueBrain> trunk is newer in many aspects
09:16:38 <Xaroth_> that might need some fine-tuning then
09:17:17 <TrueBrain> that is why I wonder if a) you should branch, and on what versions (backporting is a bitch btw, for any project), and b) if the trunk nightlies should not be 0.2.0.340 in such case
09:17:26 <TrueBrain> (and the 0.1 branch 0.1.1.341
09:17:37 <TrueBrain> where 0.1.0 is never used after its release
09:18:19 <Xaroth_> well, scratch out the branching and it all works
09:18:35 <Xaroth_> release 0.1, trunk 0.1.0.r
09:18:46 <TrueBrain> branching is not important now, but later on it becomes important, as you make a given version very stable
09:19:01 <TrueBrain> (without holding back main development)
09:19:12 <Xaroth_> but in a case of branching, 0.1.1 would be the branch version then.
09:19:26 <TrueBrain> you branch 0.1, you tag 0.1.1, I say
09:20:28 <TrueBrain> Xaroth_: that or we need to work the other way around: new development happens in branches (doesn't have to be in SVN :p)
09:20:39 <TrueBrain> when you want to merge, trunk 'freezes' for a week orso, allowing you to do so
09:20:51 <TrueBrain> then you never branch, as trunk is always fairly stable
09:20:59 <TrueBrain> (I personally don't like the idea of a stable trunk, but okay :))
09:21:09 <Xaroth_> trunk should be development, tbqfh
09:21:25 <TrueBrain> but nevertheless, that might work
09:21:31 <TrueBrain> as you avoid unneeded spam in trunk too
09:21:49 <TrueBrain> as long as you can freeze it to allow merges :)
09:22:15 <TrueBrain> but okay, we go with your scheme, and we will see where it will lead us :)
09:22:31 <TrueBrain> trunk is 0.1.0.<revision>, no branching, only tagging
09:35:07 <Xaroth_> TrueBrain: not like we'll need branching for a few months anyhow :)
09:35:12 <Xaroth_> after that we can review/alter it
09:47:38 <Xaroth_> glx should get himself a forum account as well tbh :P
09:55:43 *** Xaroth_ is now known as Xaroth
10:37:26 *** Xaroth_ has joined #openDune
11:30:25 <TrueBrain> bah, trying to find a clever way to collect enough data for my 'stage2' decompiler :p Which basicly assumes it once was C :)
11:30:44 <TrueBrain> when it reads a emu_push(emu_bp); emu_bp = emu_sp; it knows a new function begins
11:30:51 <TrueBrain> but it is tricky ..
11:31:47 <TrueBrain> SmatZ: btw, I was thinking: do you think it would be a benefit to make the code C99 or even C89 compatible?
11:34:37 <SmatZ> TrueBrain: it depends on you :) I like code purity, but some limitations are just ugly
11:34:56 <TrueBrain> the reason I ask it because I like purity too :)
11:35:09 <TrueBrain> and currently, if I got this right, 3 unions hold back C99
11:35:16 <SmatZ> hard to find a girl, right?
11:35:22 <TrueBrain> and C89 is mostly due to the local variables defined when used
11:36:02 <SmatZ> OTTD is very far from std too
11:36:09 <TrueBrain> but that is a lost cause
11:36:20 <TrueBrain> OpenDUNE can be put in a certain direction
11:37:05 <TrueBrain> I guess using named structs is ugly, but it is just that: ugly. And a tiny bit more typing
11:37:15 <TrueBrain> instead of emu_ax.h you have to write emu_ax.u.h, or what ever
11:37:43 <TrueBrain> so I wonder if it is really worth using emu_ax.h, and not being C99, over using emu_ax.u.h and being C99
11:38:03 <TrueBrain> the same goes for local variable problems .. if that is all that is keeping it back from C89, is it worth it?
11:38:51 <SmatZ> it currently works with -std=c99 -fms-extensions, right?
11:39:18 <SmatZ> tst2.cpp:4: error: ISO C++ prohibits anonymous structs
11:39:29 <SmatZ> g++ tst2.cpp -o tst2.o -c -std=c++0x -pedantic
11:41:52 <TrueBrain> or just some small effort, and slightly less readable code?
11:43:09 <TrueBrain> well, I can make a define for emu_al to be emu_ax.u.l
11:44:03 <TrueBrain> hmm ... C++ comments IS annoying
11:44:18 <SmatZ> I think it's allowed in C99
11:44:31 <Xaroth_> if it compiles, ship it! :P
11:44:41 <Xaroth_> and no, i didn't have spacecake for lunch
11:45:56 <TrueBrain> k, making it C99 is relative easy
11:46:19 <SmatZ> the idea with #define reg_al is nice
11:46:21 <TrueBrain> include/libemu.h:15: warning: type of bit-field 'cf' is a GCC extension
11:46:34 <TrueBrain> how do you do bitfields in C99?
11:47:07 <TrueBrain> decompiled/../src/house.h:16: warning: ISO C does not allow extra ';' outside of a function <- lol!
11:47:53 <TrueBrain> glx: about your patch: every change in decompiled/ is undone if I run the decompiler. So you would need to copy it to src/ for it to stay forever. The Called From: entries are for human reference, no need to manual update them. And if you edit the txt, and run the decompiler, it takes care of that for you ;)
11:48:10 <TrueBrain> that said, I am now working on some modifications to the decompiler to do what your patch does in the first line (calling the next function which it is part of)
11:48:16 <TrueBrain> most likely with goto labels :)
11:48:25 <SmatZ> [13:46:34] <TrueBrain> how do you do bitfields in C99? <== maybe only int is allowed? I don't know
11:48:45 <TrueBrain> nsz: do you have wise words on that subject? bitfields in C standard?
11:48:47 <glx> ok (btw I resolved 3 jumps doing that ;)
11:49:02 <glx> some are really easy to solve
11:49:16 <TrueBrain> yup .. the reason the decompiler doesn't do it, is because he hasn't seen them
11:49:34 <TrueBrain> this is because of the possible chance things rewrite theirself in memory .. but this isn't true for Dune2, so I can make the decompiler a bit smarter ;)
11:50:21 <TrueBrain> warning: overflow in implicit constant conversion <- when sending 0xF0 as int8
11:50:48 <TrueBrain> valid comment or not?
11:53:35 <TrueBrain> cool, C89 compatible ;)
11:53:54 <TrueBrain> okay, I should write that differently: the decompiler now makes C89 compatible output :p
11:54:42 <TrueBrain> glx: I am sure they are ;)
11:54:54 <TrueBrain> there are several very big loops via jumps
11:55:32 <nsz> bitfields were in c89 as well
11:56:01 <nsz> you can use any integer type but unsigned int is recommended
11:56:02 <TrueBrain> nsz: GCC tells me it is a GCC extension
11:56:36 <TrueBrain> where unit16 is unsigned short
11:57:04 <glx> should work for msvc too (because we make it think the source is C++)
11:57:15 <TrueBrain> warning: type of bit-field 'cf' is a GCC extension
11:57:23 <TrueBrain> maybe that it comes from a 'short' is the problem?
11:58:19 <nsz> oh is it inside a struct?
11:59:20 <nsz> try struct {unsigned int foo:1;}
11:59:33 <TrueBrain> when I make it an uint32, the warning goes away
12:00:04 <TrueBrain> just then the struct is 4 bytes instead of 2 ..
12:00:37 <Xaroth_> why not just ignore the warning? :o
12:00:40 <nsz> ok in ansic only int and unsigned int is allowed
12:00:52 <nsz> i thought c99 allows any integer type
12:00:59 <TrueBrain> I am trying C89 now
12:01:11 <TrueBrain> -pedantic -ansi -std=c89 :p
12:01:26 <nsz> you should youse unsigned as it does not matter (you specifiy the bit count explicitly)
12:01:50 <TrueBrain> might it be that __attribute__((packed)) doesn't work in such cases?
12:02:18 <TrueBrain> well ... my asserts_compile all fail
12:02:26 <SmatZ> TrueBrain: try "-std=c99 -pedantic" instead of "-pedantic -ansi -std=c99"
12:02:32 <nsz> struct {unsigned int foo:1; unsigned bar:1;} won't have 64 bits
12:02:47 <SmatZ> as... -pedantic before -std may enable some warnings
12:03:25 <SmatZ> that's what I said: remove -ansi, move -pedantic after -std=c99
12:03:27 <nsz> it has no effect when c99 is specified at the end
12:03:28 <TrueBrain> I really am trying C89 now .. as there are very minor things to change to make that happen
12:04:10 <SmatZ> nsz: gcc -Wxxx -std=yyy can have different behaviour than -std=yyy -Wxxx
12:04:11 <glx> you'll need to move many variable declarations ;)
12:04:37 <TrueBrain> glx: only in the work I have done in src/, yes :) But as that is just 2000 lines, that is now still possible
12:04:53 <nsz> variable declaration should be in the beginning of a block
12:04:57 <TrueBrain> I now removed all src/* files, and work with the decompiler output only .. C89 works :p
12:05:06 <nsz> mixed declaration and statements in c99 is stupid
12:05:08 <glx> nsz: yes, but it's not the case for now
12:05:22 <TrueBrain> I disagree with you nsz, but we already talked about that :) Ghehe :)
12:05:38 <TrueBrain> I don't mind .. if it makes the project more acceptable for other compilers, at the beginning of the block it is! :)
12:05:54 <glx> the other solution is to declare the code to be c++ and not c89 :)
12:07:04 <TrueBrain> adding __attribute__((packed)) seems to help
12:07:18 <TrueBrain> no warning about the fact it is GCC only :p
12:08:01 <nsz> well there are no packedness/alignment guarantees in the standard
12:08:58 <TrueBrain> that really sucks ...
12:09:05 <nsz> then use enum {cf=1;...} flags;
12:09:54 <TrueBrain> I can survive the flags struct
12:10:00 <TrueBrain> the problem is more later on, attaching Unit struct and stuff
12:11:17 <TrueBrain> hmm .. they do seem to pass assert_compile ...
12:11:39 <TrueBrain> warning: comma at end of enumerator list <- stupid warning :p
12:12:31 <TrueBrain> if I am going to do this, I want to do this good :) So -ansi -pedantic or -std=gnu99 :p
12:12:53 <nsz> c89 does not allow end comma
12:13:07 <TrueBrain> k ... basicly it works
12:13:13 <TrueBrain> just the src/ code now needs transforming
12:13:22 <TrueBrain> it really sucks // is not allowed ...
12:13:55 <TrueBrain> that could be C++ for all I care ;)
12:14:00 <TrueBrain> in a few months, it should be completely gone :)
12:14:30 <TrueBrain> k, something to work on a bit more tomorrow :)
12:14:37 <TrueBrain> SmatZ / nsz / glx: tnx :)
12:14:46 <nsz> what's wrong with /* */ you generate that code anyway?
12:14:49 <TrueBrain> glx: when done, you should try to compile with MSVC in C mode again :)
12:14:59 <TrueBrain> nsz: in src/unit.h for example, I use // to comment struct entries
12:15:06 <TrueBrain> that is much more readable than /* */
12:15:09 <glx> TrueBrain: yeah I though about it :)
12:15:32 <Xaroth_> glx: you should make a forum account on forum.opendune.org ;) ;)
12:15:37 <TrueBrain> either way, I really have to go :)
12:15:54 <TrueBrain> Have a good day all!! And again tnx for all the input :)
12:16:03 <Xaroth_> so you can also somewhat follow what we're up to :)
12:16:14 <TrueBrain> btw, SmatZ, if you have anything else .. now you/we can mold this project :) In a month we no longer can ;)
12:16:41 <Xaroth_> in a month we'll have 0.1 :P
12:17:17 <Xaroth_> TrueBrain: btw, good thing we're not releasing on okt 1
12:17:22 <Xaroth_> that means jan 1, and then apr 1
12:37:58 <Xaroth_> me, an information freak? naaaah
12:38:02 <Xaroth_> i just like to know a lot..
12:49:50 <SmatZ> Xaroth_: can't spaces in version string cause some problems?
13:23:56 <Xaroth_> you can always split them up, uint8 major, minor, release, uint32 revision, char** suffixes (suffice?)
13:35:23 <Xaroth_> that way you can also compare them in a network environment
13:57:23 <Xaroth_> glx: I take it you always have your name in full lowercase?
13:58:16 <glx> my nick is always lowercase yes
13:59:59 <Xaroth_> made a sig for ye then :)
14:00:10 <Xaroth_> still had the psd on this pc so easy adjusting :)
18:17:22 *** Alberth has joined #openDune
18:19:17 <Alberth> Program Termination: jumped to 10E4:0915, which is not decompiled.
18:19:17 <Alberth> The jump was triggered at decompiled/cs__10E4.c:2920
18:19:17 <Alberth> The jump appears to originate from 10E4:08BE.
18:21:28 <Alberth> btw while merging changes, my copy still contains some added comment lines from a manually applied patch.
19:06:13 *** Xaroth|mobile has joined #openDune
19:07:52 <Xaroth|mobile> androidirc looks a LOT like irssi... minus Theo userlist...
19:08:51 <Xaroth|mobile> note to self, autocorrect FAILS
19:14:22 <Alberth> now you must apply self.correct()
19:15:38 <Alberth> Program Termination: jumped to 4206:057B, which is not decompiled.
19:15:38 <Alberth> The jump was triggered at decompiled/cs__B4A2.c:1833
19:15:38 <Alberth> The jump appears to originate from B4A2:0569.
19:45:44 <Xaroth_> ooo more for the collection
20:10:26 <Alberth> Program Termination: jumped to 0C3A:0D56, which is not decompiled.
20:10:26 <Alberth> The jump was triggered at decompiled/cs__0C3A.c:3761
20:10:26 <Alberth> The jump appears to originate from 0C3A:0D51.
20:10:40 <Xaroth_> 0c3a is what I'm working on
20:10:48 <Xaroth_> lemme guess, it happened when you were trying to build something?
20:11:12 <Xaroth_> top of 0c3a is Building_Create
20:11:35 <Alberth> wow, actual readable function names already :p
20:12:23 <Xaroth_> I'm still fighting with getting it all to work
20:12:58 <Alberth> what are you working on?
20:13:00 <Xaroth_> ASM is quite annoying to figure out at times
20:13:11 <Xaroth_> I'm working on Building_Create
20:13:44 <Alberth> I find it amazing you can make any sense of it at all.
20:14:09 <Xaroth_> heh, especially if you know that I normally stick to C# .. never done C/C++ besides a patch or two for ottd
20:14:41 <Alberth> this must firmly place you back on the ground then :)
20:15:55 <Xaroth_> well if yer used to the whole System.Something.Something.Something() stuff this is quite.. back to the roots :P
20:16:44 <Xaroth_> but that's also why I'm doing more the job of managing stuff
20:17:05 <Xaroth_> leaving the people in charge of development that actually know most of this stuff :P
20:17:42 <Xaroth_> and in between try to learn as much of C/C++ as possible so i can help out in any way possible
20:17:52 <Alberth> I do a lot of Python coding @ work nowadays, so I understand it. I also did do some assembly, but that was in the era of the 6502 (a 8 bit machine with a whopping 32KB :) )
20:19:07 <Alberth> unfortunately, I am too busy with OpenTTD to do work on OpenDune
20:19:34 <Xaroth_> :) producing crashlogs is more than helpful by itself :)
20:19:50 <Xaroth_> points us to things that need work on
20:20:06 <Alberth> I can do that while compiling :p
20:21:17 <Alberth> well, good luck with 0c3a, and see you again in one or two days.
20:21:25 <Xaroth_> heh, cheers for the help :)
20:21:32 <Xaroth_> oh, nov 1 is launch of 0.1
20:21:49 <Xaroth_> also my beerday, so i expect you drunk on irc :P
20:22:08 <Xaroth_> (will be the most drunk release day ever :P)
20:22:23 <SmatZ> umm that's responsible :)
20:22:29 <Alberth> hmm, that is going to be a problem, I don't drink alcohol
20:22:45 <Xaroth_> but i know my mates will be :P
20:23:05 <SmatZ> how comes so many people don't drink?
20:23:21 <SmatZ> Rubidium, now Xaroth and Alberth...
20:23:27 <SmatZ> and sure other people I forgot :-p
20:23:38 <Xaroth_> When I was young i was a bartender at the local football club (mind, I was 7 and got paid in candy)
20:24:04 <Xaroth_> at that time i liked beer.. but that soon changed and now I can drink it, but I don't enjoy it
20:24:22 <Xaroth_> only alcoholic thing i can drink, is blue curacao.. and that only if it's mixed with a lot of orange juice
20:24:49 <Xaroth_> missus shouldn't be drinking alcohol, she had one of her kidneys taken out, so it reacts to alcohol
20:26:04 <Xaroth_> my best friend likes to make up for both of us though
20:26:28 <Xaroth_> though he's been slowing down on the drinking kegs of beer lately
20:27:54 <SmatZ> it's not good to drink >1 beer / day
20:37:45 <Xaroth_> tbh, that should be >0 :P
20:54:37 <Xaroth_> bah, still can't find a replacement for redmine
20:54:58 *** Xaroth_ is now known as Xaroth
20:55:03 *** ChanServ sets mode: +o Xaroth
20:56:45 <Xaroth> we got a bugtracker, we got a svn repo browser, we got a forum, we got a wiki
20:56:53 <Xaroth> now we only need something nice to put as frontpage
21:01:07 <nsz> "Post subject: Release Information"..
21:01:27 <nsz> xaroth, aren't you overmanaging things a bit? ;)
21:02:06 <nsz> even releas schedule until the end of 2010
21:13:36 <Xaroth> TB said every 3 months
21:13:40 <Xaroth> so i made a nice schedule :)
21:13:49 <Xaroth> I can always edit posts later
21:14:13 <Xaroth> but for now it shows people that there's something waiting nov1
21:14:26 <Xaroth> so people will become curious what it'll be like
21:42:05 <TrueBrain> nsz: we need to keep Xaroth busy in some way ;)
21:52:17 <Xaroth> well if i get pissed off at trying to convert thigns i'll just rant elsewhere ^^
21:53:34 <TrueBrain> okay, the flags is now 4 bytes long
21:53:38 <TrueBrain> flags.all is 2 bytes
21:53:46 <TrueBrain> does it pick the same 2 bytes as the struct
21:54:00 <TrueBrain> or is there anything I can do to control that ...
22:13:03 <DorpsGek> SVN: truebrain (r175) -Codechange: make the header files C89 compatible
22:13:29 <TrueBrain> tomorrow I will make decompiled/ C89 compatible
22:13:34 <TrueBrain> after which the rest of src/ can be done :)
22:13:36 <TrueBrain> for now, good night :)
22:15:57 <TrueBrain> (the downside is that I can't fix up Alberths found problems :p As my SVN is ... heavily modified ;)
22:16:04 <TrueBrain> oh well, I stored them, will do them soon :)
22:16:12 <TrueBrain> nice job btw on the forum post, it looks good
22:16:15 <TrueBrain> make sure to wikify it too
22:16:25 * TrueBrain no like forum posts for permanent records ... for that you have a wiki :)
22:19:53 <Xaroth> but the forum posts are for the brilliant people who -do- know how to use the search feature
22:27:23 <DorpsGek> SVN: truebrain (r176) -Documentation: one missing @param for one function
23:09:43 <DorpsGek> SVN: truebrain (r177) -Codechange: make the include-files C89
23:10:15 <DorpsGek> SVN: truebrain (r178) -Codechange: make the decompiled/ code C89 and integrated changed made in r177
23:10:32 <DorpsGek> SVN: truebrain (r179) -Codechange: make the src/ code C89 and integrated changes made in r177
23:11:00 <DorpsGek> SVN: truebrain (r180) -Add: switch the Makefile to '-ansi -pedantic' (C89 code)
23:11:19 <DorpsGek> SVN: truebrain (r181) [LibEMU] -Update: update include dir to latest
23:11:52 <DorpsGek> SVN: truebrain (r182) [LibEMU] -Codechange: make LibEMU C89 and integrated changes made in r177
23:13:34 <TrueBrain> weird way of going to bed I have ....
23:13:50 <TrueBrain> it leaves a few warnings .. I will fix most of them (if not all) tomorrow (for real)
23:14:01 <TrueBrain> at least GCC compiles it with -ansi -pedantic ;)
23:14:07 <glx> many "overflow in implicit constant conversion"
23:14:18 <glx> looks like the warnings I had with MSVC
23:14:33 <Xaroth> TrueBrain codes while asleep
23:14:35 <TrueBrain> > 0x80 casting to (int8)
23:15:03 <TrueBrain> won't work: variables are still defined everywhere
23:16:04 <TrueBrain> it is only a warning for GCC, so that allowed me to split that job :)
23:16:17 <TrueBrain> well .. first commit rampage we have seen ;)
23:16:40 <TrueBrain> so tomorrow I first fix the ones that keep MSVC back
23:16:44 <TrueBrain> then I will fix the other warnings
23:16:50 <TrueBrain> then we enable that a warning is an error ;)
23:17:21 <TrueBrain> after that, I will look at SmatZ to see if he has some weird compilers to test OpenDUNE with/on :)
23:17:28 <glx> src/unit.c:66: warning: ISO C90 forbids mixed declarations and code <-- I though you said C89 :)
23:17:42 <TrueBrain> hmm .. maybe nsz didn't tell the truth about -ansi ;)
23:17:59 <TrueBrain> In C mode, this is equivalent to -std=c89.
23:18:02 <TrueBrain> so GCC is the one the blame ;)
23:22:06 <TrueBrain> then next I have figured out a nice way to optimize the decompiled code more
23:22:18 <TrueBrain> it will try to find and isolate seperate functions, as they were in C
23:22:22 <TrueBrain> and present them as a single function
23:22:36 <TrueBrain> after that I guess I can try to see if I can make it detect the amount of parameters used and stuff
23:23:07 <TrueBrain> today I was reading src/input/mouse.c
23:23:09 <TrueBrain> it made me laugh :)
23:23:27 <TrueBrain> I learnt so much in the last few days/weeks about how to convert files ... src/input/* is UGLY as hell :p
23:24:04 <TrueBrain> then as last on my agenda is figuring out a way to make conversion a bit simpler .. if you check random emu_ files, it contains a lot of the same ..
23:24:12 <TrueBrain> but now, for real: good night :)
continue to next day ⏵