====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:lynusvaz:journal:week7 [2009/07/07 23:27] lynusvaz |
soc:2009:lynusvaz:journal:week7 [2009/07/12 11:46] (current) lynusvaz |
||
|---|---|---|---|
| Line 10: | Line 10: | ||
| * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=59e72569d3875d34cd74fa914543fa36e96f744a|Using the offset for loops]] | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=59e72569d3875d34cd74fa914543fa36e96f744a|Using the offset for loops]] | ||
| * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=2fd7543a960c7d18ff5bf6fbe4f75cbfcce10bfb|Support for incomplete lines]] | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=2fd7543a960c7d18ff5bf6fbe4f75cbfcce10bfb|Support for incomplete lines]] | ||
| + | |||
| + | July 8: Implemented incomplete arithmetic expressions, on top of yesterday's code. After that, I spent some time just having a look at the memory allocation and freeing, and making sure the free memory before and after the shell matched up. Everything seemed fine. So now I think loops are almost done, and I can start on the next task: return codes. Having a variable to check the success of the previous command would be very useful. However, we also have to make sure that existing scripts work: current gPXE behaviour is to terminate a script at an unsuccessful command. So, we need a way to let a script optionally use the new behaviour or fall back to the old method. | ||
| + | #!gpxe --no-exit | ||
| + | #rest of script | ||
| + | or another way could be: | ||
| + | #!gpxe | ||
| + | set -e 1 # The value of -e could have a default of 0 to have the old behaviour | ||
| + | #rest of script | ||
| + | Besides this, we need to have a variable to denote the return code of the previous statement, say ${rc}. I put in the part of setting rc with the previous return code. Now the only thing required is to decide on the way the script could request the new behaviour. | ||
| + | Today's commit: | ||
| + | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=91392fd1c3f29880ef3b307e8d9c4e548a5a6e9e|Incomplete arith expressions]] | ||
| + | |||
| + | July 9: Implemented a first attempt at using return codes, using the --no-exit idea. This looks for a #!gpxe<space(s)/tab(s)>--no-exit line at the beginning of the script. Then, after each command is executed, the value of the variable rc is set to the return code of the command. So, the script/user can check the success of a command by looking at the value of the rc variable. An interesting idea that came up was using a stack to store the return code. So, ${rc/0} would be the return code of the previous command, ${rc/1} of the command before that and so on. This would mean implementing rc as a settings block, so I've started reading through core/settings.c to see how I can do that. | ||
| + | Today's commit: | ||
| + | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=3bda90e89921b4963f85e79c2fcefa446972a1dc|--no-exit option with ${rc}]] | ||
| + | |||
| + | July 10: I was out for most of today, and was able to work only in the evening. Tried to make a settings block, but ran into some trouble. ${rc/0} works, but ${rc/1} does not. That's because it sees the number as a tag, and looks for the corresponding setting, which doesn't exist. Then, I tried making a setting and adding it to the generic_settings list, but that doesn't work, either: it still looks for a tag. I'll try it again tomorrow. No commits today. | ||
| + | |||
| + | July 11: An interesting idea about the return code was to use a try-catch block instead of the rc stack: | ||
| + | try | ||
| + | kernel tftp://10.0.0.2//kernel | ||
| + | initrd tftp://10.0.0.2//initrd | ||
| + | boot | ||
| + | catch | ||
| + | echo "Boot failure" | ||
| + | done | ||
| + | Basically, the try-catch block works as an if-else block that can change its truth value as a statement fails. This fits in well with the work on branches and loops. So, I'm going to use this instead of the rc stack. In today's meeting, we discussed a few issues: | ||
| + | * Modifying the project plan to make it more specific | ||
| + | * Writing code with more focus on merging | ||
| + | |||
| + | July 12: Worked on adding try-catch statements to the scripting language. There is one issue though: what happens to loops inside a try block, e.g. | ||
| + | try | ||
| + | for i in 0 1 2 3 | ||
| + | do | ||
| + | ... | ||
| + | done | ||
| + | catch | ||
| + | ... | ||
| + | done | ||
| + | Stefan and I decided that the execution should immediately jump to the catch block. | ||
| + | Today's commits: | ||
| + | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=fc1265c3b28b30406127f87d7cf0dc916216f299|Try-catch-done]] | ||
| + | * [[http://git.etherboot.org/?p=people/lynusvaz/gpxe.git;a=commit;h=9b358af784b5691b77455fb3823b124b1f904c9d|Added a flags field to struct command.]]This will help shorten the execv() function, and help in extending, if required later. | ||
