Difference between revisions of "User:Lkates"

From CDOT Wiki
Jump to: navigation, search
(revert)
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
My homepage.  Useful content to come.
+
Lorne Kates' User Page.
  
−
My project: [[%22Avoid_loading_the_same_page_twice%22_Extension]]
+
=Me=
 +
I'm a 4/5/6/7th semester BSD student.  I transferred in after completing CTY.  Since the programs are similar yet different, I'm taking courses from all over the cirriculum.
 +
 
 +
In my spare time (what little there is), I pursue a myrid of hobbies in a very Jack-of-all-Trades manner.  I read, write, play the guitar, and cook.  My first short story was published earlier this year in the anthology [http://www.chapters.indigo.ca/books/item/books-978088995340/0889953406/Mythspring?ref=Search+Books%3a+'mythspring' Mythspring]
 +
 
 +
I also run a yard haunt in Newmarket.  Pictures from 2004, and some from 2005, are [http://houghtonhaunt.com posted on the haunt's site].
  
 
My email:  lkates@learn.senecac.on.ca
 
My email:  lkates@learn.senecac.on.ca
 +
 +
IRC handle:  halcyon1234
 +
 +
=BTP600=
 +
 +
BTP600 course material goes here.  I wouldn't mind doing the Wikipedia Design Pattern stub.
 +
 +
==Code Reading Exercise==
 +
 +
Looking at MAKE and ???
 +
 +
#Which file(s) did you have to examine?
 +
 +
'''make'''
 +
First I looked at loadargc, since argc reminds me of the C/C++ standard command line variables that you use in main.  However, that turned out to be a load balancing program.  Next I looked at Main.h, since main seems like a good start, and headers tend to define stuff.  But there wasn’t anything useful there.  So I opened Main.c, and voila!  Code that has to do with command line switches.
 +
 +
. What are your first reactions to these files when you examine them?
 +
 +
'''make'''
 +
I don’t think I can put them down, in accordance to Seneca’s Acceptable Use Policy.  But the sheer amount of code and underscores and structs were a bit overwhelming.
 +
 +
. How is the code for working with command-line switches organized at the method, class and project levels? (e.g. is is all in one class? broken across multiple classes? spread across many methods? etc)
 +
 +
'''make'''
 +
There are a couple methods defined right near the beginning:
 +
 +
<code>
 +
static void decode_switches PARAMS ((int argc, char **argv, int env));
 +
static void decode_env_switches PARAMS ((char *envar, unsigned int len));
 +
</code>
 +
 +
Almost immediately afterwards, there's the structure for an acceptable command line switch
 +
 +
<code>
 +
/* The structure that describes an accepted command switch.  */
 +
 +
struct command_switch
 +
  {
 +
    int c; /* The switch character.  */
 +
 +
    enum /* Type of the value.  */
 +
      {
 +
flag, /* Turn int flag on.  */
 +
flag_off, /* Turn int flag off.  */
 +
string, /* One string per switch.  */
 +
positive_int, /* A positive integer.  */
 +
floating, /* A floating-point number (double).  */
 +
ignore /* Ignored.  */
 +
      } type;
 +
 +
    char *value_ptr; /* Pointer to the value-holding variable.  */
 +
 +
    unsigned int env:1; /* Can come from MAKEFLAGS.  */
 +
    unsigned int toenv:1; /* Should be put in MAKEFLAGS.  */
 +
    unsigned int no_makefile:1; /* Don't propagate when remaking makefiles.  */
 +
 +
    char *noarg_value; /* Pointer to value used if no argument is given.  */
 +
    char *default_value;/* Pointer to default value.  */
 +
 +
    char *long_name; /* Long option name.  */
 +
  };
 +
</code>
 +
 +
 +
Main.c then goes on to define a usage output, that is used to define, in English, how to use all the different flags.  Presumably, this is used when the /h switch is used
 +
 +
<code>
 +
/* The usage output.  We write it this way to make life easier for the
 +
  translators, especially those trying to translate to right-to-left
 +
  languages like Hebrew.  */
 +
 +
static const char *const usage[] =
 +
...
 +
    N_("\
 +
  -h, --help                  Print this message and exit.\n"),
 +
...
 +
</code>
 +
 +
 +
Afterwards, there is a table of the command switches, along with a bunch of flags and numbers I don't understand.
 +
 +
<code>
 +
/* The table of command switches.  */
 +
static const struct command_switch switches[] =
 +
    { 'b', ignore, 0, 0, 0, 0, 0, 0, 0 },
 +
    { 'B', flag, (char *) &always_make_flag, 1, 1, 0, 0, 0, "always-make" },
 +
...
 +
</code>
 +
 +
 +
It also defines "long names" for short switches, like when you use --help rather than /h
 +
 +
<code>
 +
/* Secondary long names for options.  */
 +
static struct option long_option_aliases[] =
 +
  {
 +
    { "quiet", no_argument, 0, 's' },
 +
    { "stop", no_argument, 0, 'S' },
 +
    { "new-file", required_argument, 0, 'W' },
 +
    { "assume-new", required_argument, 0, 'W' },
 +
    { "assume-old", required_argument, 0, 'o' },
 +
    { "max-load", optional_argument, 0, 'l' },
 +
    { "dry-run", no_argument, 0, 'n' },
 +
    { "recon", no_argument, 0, 'n' },
 +
    { "makefile", required_argument, 0, 'f' },
 +
  };
 +
</code>
 +
 +
 +
Main.h also defines a structure called "file", which has error handling in it for empty filenames:
 +
 +
<code>
 +
static struct file *
 +
enter_command_line_file (name)
 +
    char *name;
 +
{
 +
  if (name[0] == '\0')
 +
    fatal (NILF, _("empty string invalid as file name"));
 +
</code>
 +
 +
Shortly after, main goes into its main() function.  It starts to do a bunch of crazy stuff with backslash conversion and allocating temp space for variables and stuff.  After its done that, it goes ahead and re-interprets the command line switches, in case Make itself has added any:
 +
 +
<code>
 +
  /* Decode switches again, in case the variables were set by the makefile.  */
 +
  decode_env_switches ("MAKEFLAGS", 9);
 +
#if 0
 +
  decode_env_switches ("MFLAGS", 6);
 +
#endif
 +
</code>
 +
 +
 +
It then goes into a bunch of "goal files", which are, as far as I can tell, files that have to be made.  If none are specified, but are expected, it dies:
 +
 +
<code>
 +
  if (!goals)
 +
      {
 +
        if (read_makefiles == 0)
 +
          fatal (NILF, _("No targets specified and no makefile found"));
 +
 +
        fatal (NILF, _("No targets"));
 +
      }
 +
</code>
 +
 +
'''Ant'''
 +
Opening main.java yeilds some gold right off the bat:
 +
 +
<code>
 +
/**
 +
* Command line entry point into Ant. This class is entered via the
 +
* canonical `public static void main` entry point and reads the
 +
* command line arguments. It then assembles and executes an Ant
 +
* project.
 +
* <p>
 +
* If you integrating Ant into some other tool, this is not the class
 +
* to use as an entry point. Please see the source code of this
 +
* class to see how it manipulates the Ant project classes.
 +
*
 +
*/
 +
public class Main implements AntMain {
 +
</code>
 +
 +
 +
Right after, there's more gold
 +
 +
<code>
 +
    /**
 +
    * Creates a new instance of this class using the
 +
    * arguments specified, gives it any extra user properties which have been
 +
    * specified, and then runs the build using the classloader provided.
 +
    *
 +
    * @param args Command line arguments. Must not be <code>null</code>.
 +
    * @param additionalUserProperties Any extra properties to use in this
 +
    *        build. May be <code>null</code>, which is the equivalent to
 +
    *        passing in an empty set of properties.
 +
    * @param coreLoader Classloader used for core classes. May be
 +
    *        <code>null</code> in which case the system classloader is used.
 +
    */
 +
    public static void start(String[] args, Properties additionalUserProperties,
 +
                            ClassLoader coreLoader) {
 +
</code>
 +
 +
Such nice documentation!
 +
 +
Soon after, I encountered a method that "processes command line arguments"  Sweet!
 +
 +
<code>
 +
/**
 +
    * Process command line arguments.
 +
    * When ant is started from Launcher, the -lib argument does not get
 +
    * passed through to this routine.
 +
    *
 +
    * @param args the command line arguments.
 +
    *
 +
    * @since Ant 1.6
 +
    */
 +
    private void processArgs(String[] args) {
 +
</code>
 +
 +
It goes on to parse each possible command line argument (and its long name equiv), check it for existence, proper structure, and throws exceptions where appropriate.
 +
 +
After that, it goes to check files.
 +
 +
#How are invalid or non-existent Filenames dealt with?
 +
 +
'''make'''
 +
In general, a fatal flag is put up, and the program dies.  This seems to be mostly done when the command line switches are processed.  If a file was expected (ie: a Make file, or a file specified after a switch argument), then the errors are found when the switch is processed, or the file is looked at.  This is different from what I was expecting.  I was expecting it to do mandatory file checking right off the bat (start of main function, perhaps), and dying before it did any other work.
 +
 +
 +
'''Ant'''
 +
After checking all the switches (and their appropriate files, where appropriate), in the Start function, it goes on to run a bunch of if-blocks to check for file names.  It checks for buildfile, etc.  If it ever doesn't find an expected file, it throws an exception and dies.
 +
<code>
 +
        // make sure buildfile exists
 +
        if (!buildFile.exists()) {
 +
            System.out.println("Buildfile: " + buildFile + " does not exist!");
 +
            throw new BuildException("Build failed");
 +
        }
 +
</code>
 +
 +
 +
.Find and describe 2 similarities between the code you examined in both projects.
 +
 +
.Both of the programs process switches, then look at files
 +
.Both use a seperate class/method to process the command line switches
 +
 +
.Find and describe 2 differences between the code you examined in both projects.
 +
.'''Make''' uses structures and flags to error check their flags. In a way, the switches error check themselves. '''Ant''' uses a bunch of if blocks and exceptions.  It has to error check the switches.
 +
.'''Make''' has a bunch of very obfuscated comments laced throughout the code.  '''Ant'' puts all their documentation right before each function, and each piece of documentation is, like, 3 paragraphs long and is presented in very plain English.
 +
 +
.If you have time, try modifying one of the programs to add a new command-line switch that is your learn ID. The switch doesn't have to do anything, or can do something very trivial. (A prize to the first group that does this successfully!)
 +
 +
Sure, we'll see.
 +
 +
=Other Wiki Courses=
 +
[[lkates:dps909]]

Latest revision as of 16:10, 10 April 2007

Lorne Kates' User Page.

Me

I'm a 4/5/6/7th semester BSD student. I transferred in after completing CTY. Since the programs are similar yet different, I'm taking courses from all over the cirriculum.

In my spare time (what little there is), I pursue a myrid of hobbies in a very Jack-of-all-Trades manner. I read, write, play the guitar, and cook. My first short story was published earlier this year in the anthology Mythspring

I also run a yard haunt in Newmarket. Pictures from 2004, and some from 2005, are posted on the haunt's site.

My email: lkates@learn.senecac.on.ca

IRC handle: halcyon1234

BTP600

BTP600 course material goes here. I wouldn't mind doing the Wikipedia Design Pattern stub.

Code Reading Exercise

Looking at MAKE and ???

  1. Which file(s) did you have to examine?

make First I looked at loadargc, since argc reminds me of the C/C++ standard command line variables that you use in main. However, that turned out to be a load balancing program. Next I looked at Main.h, since main seems like a good start, and headers tend to define stuff. But there wasn’t anything useful there. So I opened Main.c, and voila! Code that has to do with command line switches.

. What are your first reactions to these files when you examine them?

make I don’t think I can put them down, in accordance to Seneca’s Acceptable Use Policy. But the sheer amount of code and underscores and structs were a bit overwhelming.

. How is the code for working with command-line switches organized at the method, class and project levels? (e.g. is is all in one class? broken across multiple classes? spread across many methods? etc)

make There are a couple methods defined right near the beginning: 

static void decode_switches PARAMS ((int argc, char **argv, int env));
static void decode_env_switches PARAMS ((char *envar, unsigned int len));

Almost immediately afterwards, there's the structure for an acceptable command line switch

/* The structure that describes an accepted command switch. */

struct command_switch 

 {
   int c;			/* The switch character.  */

   enum			/* Type of the value.  */
     {

flag, /* Turn int flag on. */ flag_off, /* Turn int flag off. */ string, /* One string per switch. */ positive_int, /* A positive integer. */ floating, /* A floating-point number (double). */ ignore /* Ignored. */ 

     } type;

   char *value_ptr;	/* Pointer to the value-holding variable.  */

   unsigned int env:1;		/* Can come from MAKEFLAGS.  */
   unsigned int toenv:1;	/* Should be put in MAKEFLAGS.  */
   unsigned int no_makefile:1;	/* Don't propagate when remaking makefiles.  */

   char *noarg_value;	/* Pointer to value used if no argument is given.  */
   char *default_value;/* Pointer to default value.  */

   char *long_name;		/* Long option name.  */
 };


Main.c then goes on to define a usage output, that is used to define, in English, how to use all the different flags. Presumably, this is used when the /h switch is used

/* The usage output. We write it this way to make life easier for the 

  translators, especially those trying to translate to right-to-left
  languages like Hebrew.  */

static const char *const usage[] = ... 

   N_("\
 -h, --help                  Print this message and exit.\n"),

...


Afterwards, there is a table of the command switches, along with a bunch of flags and numbers I don't understand.

/* The table of command switches. */ static const struct command_switch switches[] = 

   { 'b', ignore, 0, 0, 0, 0, 0, 0, 0 },
   { 'B', flag, (char *) &always_make_flag, 1, 1, 0, 0, 0, "always-make" },

...


It also defines "long names" for short switches, like when you use --help rather than /h

/* Secondary long names for options. */ static struct option long_option_aliases[] = 

 {
   { "quiet",		no_argument,		0, 's' },
   { "stop",		no_argument,		0, 'S' },
   { "new-file",	required_argument,	0, 'W' },
   { "assume-new",	required_argument,	0, 'W' },
   { "assume-old",	required_argument,	0, 'o' },
   { "max-load",	optional_argument,	0, 'l' },
   { "dry-run",	no_argument,		0, 'n' },
   { "recon",		no_argument,		0, 'n' },
   { "makefile",	required_argument,	0, 'f' },
 };


Main.h also defines a structure called "file", which has error handling in it for empty filenames:

static struct file * 

enter_command_line_file (name)
    char *name;
{
 if (name[0] == '\0')
   fatal (NILF, _("empty string invalid as file name"));

Shortly after, main goes into its main() function. It starts to do a bunch of crazy stuff with backslash conversion and allocating temp space for variables and stuff. After its done that, it goes ahead and re-interprets the command line switches, in case Make itself has added any: 

 /* Decode switches again, in case the variables were set by the makefile.  */
 decode_env_switches ("MAKEFLAGS", 9);
  1. if 0
 decode_env_switches ("MFLAGS", 6);
  1. endif


It then goes into a bunch of "goal files", which are, as far as I can tell, files that have to be made. If none are specified, but are expected, it dies: 

  if (!goals)
     {
       if (read_makefiles == 0)
         fatal (NILF, _("No targets specified and no makefile found"));

       fatal (NILF, _("No targets"));
     }

Ant Opening main.java yeilds some gold right off the bat:

/** 

* Command line entry point into Ant. This class is entered via the
* canonical `public static void main` entry point and reads the
* command line arguments. It then assembles and executes an Ant
* project.
*

* If you integrating Ant into some other tool, this is not the class * to use as an entry point. Please see the source code of this * class to see how it manipulates the Ant project classes. * */ public class Main implements AntMain { </code> Right after, there's more gold <code> /** * Creates a new instance of this class using the * arguments specified, gives it any extra user properties which have been * specified, and then runs the build using the classloader provided. * * @param args Command line arguments. Must not be <code>null</code>. * @param additionalUserProperties Any extra properties to use in this * build. May be <code>null</code>, which is the equivalent to * passing in an empty set of properties. * @param coreLoader Classloader used for core classes. May be * <code>null</code> in which case the system classloader is used. */ public static void start(String[] args, Properties additionalUserProperties, ClassLoader coreLoader) { </code> Such nice documentation! Soon after, I encountered a method that "processes command line arguments" Sweet! <code> /** * Process command line arguments. * When ant is started from Launcher, the -lib argument does not get * passed through to this routine. * * @param args the command line arguments. * * @since Ant 1.6 */ private void processArgs(String[] args) { </code> It goes on to parse each possible command line argument (and its long name equiv), check it for existence, proper structure, and throws exceptions where appropriate. After that, it goes to check files.

  1. How are invalid or non-existent Filenames dealt with?
make In general, a fatal flag is put up, and the program dies. This seems to be mostly done when the command line switches are processed. If a file was expected (ie: a Make file, or a file specified after a switch argument), then the errors are found when the switch is processed, or the file is looked at. This is different from what I was expecting. I was expecting it to do mandatory file checking right off the bat (start of main function, perhaps), and dying before it did any other work. Ant After checking all the switches (and their appropriate files, where appropriate), in the Start function, it goes on to run a bunch of if-blocks to check for file names. It checks for buildfile, etc. If it ever doesn't find an expected file, it throws an exception and dies. <code> // make sure buildfile exists if (!buildFile.exists()) { System.out.println("Buildfile: " + buildFile + " does not exist!"); throw new BuildException("Build failed"); } </code> .Find and describe 2 similarities between the code you examined in both projects. .Both of the programs process switches, then look at files .Both use a seperate class/method to process the command line switches .Find and describe 2 differences between the code you examined in both projects. .Make uses structures and flags to error check their flags. In a way, the switches error check themselves. Ant uses a bunch of if blocks and exceptions. It has to error check the switches. .'Make has a bunch of very obfuscated comments laced throughout the code. Ant puts all their documentation right before each function, and each piece of documentation is, like, 3 paragraphs long and is presented in very plain English. .If you have time, try modifying one of the programs to add a new command-line switch that is your learn ID. The switch doesn't have to do anything, or can do something very trivial. (A prize to the first group that does this successfully!) Sure, we'll see.

Other Wiki Courses

lkates:dps909

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=User:Lkates&oldid=11895"