IRC logs for #opendune on OFTC at 2011-09-17
⏴ go to previous day
00:00:08 <TrueBrain> all other jumps are part of if/else statements
00:01:40 <TrueBrain> but I need to make a separate pass to detect the first group :)
08:11:52 *** planetmaker has joined #openDune
08:11:52 *** ChanServ sets mode: +v planetmaker
08:13:22 *** ChanServ sets mode: +v Yexo
08:33:19 *** Alberth has joined #openDune
08:33:19 *** ChanServ sets mode: +o Alberth
10:24:53 *** DorpsGek has joined #openDune
10:24:53 *** ChanServ sets mode: +o DorpsGek
10:54:26 <TrueBrain> yippie; normal forward if detection works
10:54:29 <TrueBrain> now how to detect else ... hmm
10:56:31 <Alberth> with a parser, usually, if you are interpreting a token stream
10:56:46 <TrueBrain> I really did not want to write a full lexer
10:56:48 <TrueBrain> but I nearly did :P
11:00:39 <Alberth> well, you can use a scannerless parser if you want to avoid writing a lexer :p
11:01:27 <Alberth> (but it merges your scanner spec into the parser, so not less work :) )
11:01:41 <TrueBrain> but in Python, a lexer is very easy
11:01:55 <TrueBrain> globals()["c_" + command](queue, params, i)
11:05:26 <TrueBrain> WOEI! This works :D
11:06:44 <TrueBrain> I only doubt about the order of parameters .. I should look that up
11:07:29 <TrueBrain> no, order is correct
11:07:32 <TrueBrain> strangly enough tbh
11:08:28 <TrueBrain> I only support a very small offset of the language atm :P Extended will be a pain
11:10:22 <Alberth> if you are using python 2, you've seem to have missed a few developments :)
11:12:37 <Alberth> oh, print(), Python 3 thus. nvm
11:13:01 <TrueBrain> I wrote it for python 2
11:13:11 <TrueBrain> but I also really dislike using print as keyword
11:14:00 <Alberth> in that case, new-style classes derive from object :)
11:14:23 <TrueBrain> yeah; but I don't care about that :P
11:14:28 <Alberth> ie class c_return(object):
11:14:28 <TrueBrain> this code is ugly in many ways
11:14:35 <TrueBrain> as you can make a parent class
11:14:38 <TrueBrain> and remove 50% of the code
11:14:55 <TrueBrain> getString and getPart are predictable
11:20:29 <TrueBrain> but it also works :D :P
11:23:31 <TrueBrain> now I need bigger snippets I guess
11:24:12 <TrueBrain> guess I should do a bit of cleaning first :P
11:24:49 <Alberth> like throwing away 50% of the code :p
11:32:26 <TrueBrain> of course I broke it ... lolz
11:35:19 <Alberth> time for version 2 :)
11:36:37 <TrueBrain> only saves 10 lines :P
11:37:27 <TrueBrain> but new classes are 4 lines instead of 20
11:38:14 <Alberth> the class header line becomes significant :)
11:38:25 <TrueBrain> no, there weren't enough that could use it :P
11:38:30 <TrueBrain> so in that respect, yes :)
11:39:48 <TrueBrain> should make you happy too :P
11:41:09 <TrueBrain> no longer Python 2.1 compatible! :P
11:43:39 <Alberth> I'd pass self.string to the node base class :)
11:44:07 <TrueBrain> owh, yeah, that is possible now
11:44:13 <Alberth> 178: for line in f: works too, ie no need to read all lines first
11:44:32 <TrueBrain> historical reasons :) I expected I would need a multi-pass
11:46:57 <TrueBrain> passing self.string is a bit slower, stricly seen :P
11:47:42 <TrueBrain> I should add function headers I guess
11:48:32 <Alberth> and a few empty lines :p
11:49:16 <TrueBrain> if 3 > team.getAverageDistance:
11:49:27 <TrueBrain> lets validate order of parameters here ..
11:49:50 <TrueBrain> right is the last on the stack, left the first
11:50:35 <TrueBrain> code is: CALL TEAM GET AVERAGE DISTANCE; PUSH RET; PUSH 3; GT
11:51:01 <TrueBrain> 3 is poped from stack, put in 'right', ret is poped from stack, put in 'left'
11:51:09 <TrueBrain> left >= right ? 1 : 0
11:52:10 <Alberth> if you say so, that explanation is a little too fast for me :)
11:52:26 <TrueBrain> script.c says: right = POP; left = POP; (in that order)
11:52:39 <TrueBrain> so PUSH RET, PUSH 3, means right = 3, left = RET, I think
11:53:18 <TrueBrain> which does leave kinda a problem ..
11:53:26 <Alberth> if turrets turn in the wrong way, you know you messed up :)
11:53:54 <TrueBrain> the order of execution is vague, at best
11:54:11 <TrueBrain> it will be: call a, push ret, call b, push ret
11:54:25 <TrueBrain> but if you decode that again .. hmm
11:54:37 <TrueBrain> well, for > it doesn't matter
11:54:51 <TrueBrain> or more likely: a and b(a)
11:55:09 <TrueBrain> push a, call b, push ret
11:55:13 <TrueBrain> owh, it is always executed
11:55:15 <TrueBrain> so it doesn't matter
11:55:21 <TrueBrain> it is not like C, where it aborts if a fails already
11:55:42 <Alberth> no short circuit evaluation :)
11:56:32 <TrueBrain> now I have to implement one of the harder commands ... ENTER
11:56:37 <TrueBrain> which means subroutine support ..... :s
12:33:12 <TrueBrain> hmm .. I have the strange feeling there is another type of jump, namely a break
12:33:21 <TrueBrain> not sure, but scoping is not working correct :P
12:35:53 <glx> scoping was a pain for noai :)
12:36:02 <TrueBrain> it always is a pain :)
12:36:20 <TrueBrain> and my error messages are not really helping either :P
12:51:50 <TrueBrain> Harvest spice search algorithm:
12:52:02 <TrueBrain> look at 3, look at 20, look at 40, look at 60 (in searchSpice)
13:05:15 <TrueBrain> ah; found why my scoping acts weird ...
13:05:21 <TrueBrain> to detect parameter count, I cheated
13:05:31 <TrueBrain> N is the amount of params if in such statements
13:05:42 <TrueBrain> I am too lazy to program how many CALL expects for every function
13:05:45 <TrueBrain> this works well, except ...
13:05:50 <TrueBrain> DROP has one other case of usage:
13:06:06 <TrueBrain> now this goes fine, unless ...
13:06:16 <TrueBrain> CALL (..) (no params)
13:25:07 <TrueBrain> parameters of functions are wrong
13:25:10 <TrueBrain> but it is really close
13:27:30 <Alberth> wow, what a lot of code
13:34:37 <TrueBrain> updates so Python compiles it
13:35:45 <TrueBrain> uploaded build and team too
13:37:36 <TrueBrain> Alberth: any code suggestions?
13:37:58 <TrueBrain> PS: I never implemented all functions, only a subset ... silly script engine, supports much more than is used :)
13:40:23 <Alberth> but all those future extensions then? :D
13:40:55 <Alberth> are you in a hurry with code suggestions?
13:40:58 <TrueBrain> I made the list, it only misses BAND, BOR, BXOR, NEG and XOR
13:41:08 <TrueBrain> not really; I wonder if I should commit this to SVN
13:41:13 <TrueBrain> in /extra or something
13:42:22 <Alberth> /extra sounds like something not needed for the game
13:43:35 <TrueBrain> uploaded a new version of everything
13:43:50 <TrueBrain> some minor stuff :)
13:44:02 <TrueBrain> I wonder if I can detect the parameters ...
13:44:39 <Alberth> will look at it tonight, I am in the middle of figuring out some data structures
13:44:49 <TrueBrain> owh, no worries; it works, so :)
14:16:40 <TrueBrain> there; parameter detection
14:16:45 <TrueBrain> updated all files :)
14:20:01 <TrueBrain> hmm .. the time my frigate delivered to a random place, seems to be related to how frigates work :P
14:20:58 <Alberth> as in 'the countdown is part of the program' ? :)
14:22:14 <TrueBrain> no; but if it can't find a palace to put you down to
14:22:21 <TrueBrain> it just randomly puts your units down
14:22:28 <TrueBrain> put you down = put your units
14:23:37 <TrueBrain> I am kinda happy with the result :)
14:25:42 <TrueBrain> hmm ... in build.emc the c0 function is called with a parameter
14:25:45 <TrueBrain> but it is never used in that function
14:25:53 <TrueBrain> now that is annoying, as then my detection fails
14:27:43 <TrueBrain> many silly things in the scripts
14:29:55 <Alberth> perhaps parameters were not optional?
14:31:21 <TrueBrain> most building scripts are not interesting at all
14:31:26 <TrueBrain> and are in fact a waste of time to do in a script
14:33:42 <TrueBrain> I am just happy 1991 was a primitive time, and the compiler they used was primitive :D
16:24:31 <Alberth> c_reserve doesn't set self.partStatement which may cause trouble. Otherwise the biggest change would seem to be to use string interpolation, like '%s(%s)' % (f_call.string, par) instead of f_call.string + "(" + par + ")" Otherwise the amount of room for improvement seems limited, there is always one case that breaks the general pattern
16:27:32 <TrueBrain> that is good to know ;)
16:27:43 <TrueBrain> and c_reserve is not used; it is ignored completely
16:27:46 <TrueBrain> never added to the list, nothing
16:28:32 <Alberth> perhaps if you set it up in a more modular form, but it probably only gets bigger
16:28:47 <TrueBrain> and this won't grow, I hope :D
16:30:56 <Alberth> doh! you can simplify the binary operators of course
16:32:04 <TrueBrain> they can go one abstract higher indeed
16:32:12 <TrueBrain> that might be a good thing to do
18:21:05 *** Sonarpulse has joined #openDune
22:56:51 *** Sonarpulse has joined #openDune
23:00:05 <Sonarpulse> anybody know where the "orthodox" location to put the installation on linux would be
23:00:10 <Sonarpulse> .deb would be nice too
23:02:57 <TrueBrain> any location will do; as long as the files are there
23:17:13 <Sonarpulse> I have it on my desktop right now
23:17:19 <Sonarpulse> and it works great
23:17:39 <Sonarpulse> but I would like to put it were it belongs
23:17:54 <TrueBrain> no FHS support yet, so any place is as good as the next
23:18:00 <TrueBrain> and it belongs where ever you want it to belong
23:19:00 <Sonarpulse> aha FHS support would mean putting the main executable in /usr/bin and other stuff in elsewhere
23:19:12 <TrueBrain> but it needs everything in a single directy
23:19:24 <TrueBrain> till that gets fixed, it will be like it is now :)
23:19:25 <Sonarpulse> single directory currently?
23:21:55 <Sonarpulse> if i wanted to check out the code would i do:
23:22:12 <Sonarpulse> svn co svn.opendune.org
23:22:24 <TrueBrain> I would take the /trunk, but yes
23:22:29 <TrueBrain> svn co svn://svn.opendune.org/trunk
23:46:07 <Sonarpulse> I was trying to submit the "bug" about the readme saying the mac version included libSDL i mentioned in the forums awhile back
23:46:40 <Sonarpulse> and the bugtrack said I wasn't filling out some captcha or something?
continue to next day ⏵