Instructor: Lane A. Hemaspaandra
TA: Stan Park
Note that even if you do the above things, sometimes browsers hold things without rechecking them. This most typically happens on things such as postscript documents called by links from web pages (even when it knows to recheck the web page each time, a browser may be too lazy to do that for files in its cache). If you have problems with that, simply emptying your cache should get you the fresh version of the object. Note that in Netscape/Mozilla/Firefox, if you find that it seems not to be grabbing the most current version of a web page (and on some browsers, using the forward/back buttons evades even the most emphatic preference settings), it often helps to simply use Shift-[ReloadButton] to tell it, "Go check again."
Disclaimer: Hey, I'm a theory professor, so I'm probably the worst person imaginable to take advice from on taming your browser.
P.S. A bit of additional browser help, from a Firefox fan:
[Here is] how to tune cache settings for Firefox. The following steps are used do it: 1) Type "about:config" (without quotes) in URL bar, press ENTER, 2) Find key "browser.cache.check_doc_frequency", 3) Change value to "1", which means "Check every time I view the page". That should do it. The default is "3 (default): Check when the page is out of date (automatically determined)", but that does not always work.
Here is one sample NFA program. Here are some sample inputs. Note however that we have not written an interpreter for NFAs. So the only way you'll be able to use this input file is to, after compiling the sample NFA into a DFA, to use the input file as sample inputs to the DFA.
Here is one sample DFA program (the language it accepts is, unless I botched it, (010)^*(1+00+011+011(0+1))) and here are some sample inputs.
Groups for Project 2 (note: if people add/drop such
people will go in/out of groups):
Group G: Alex, Andrew, Jules, Wyatt.
Group R: Bryan, Emily, Gabriel, Ian, James.
Group S: Damian, Dennis, Jake, Joseph, Sagar.
The three group names
and memberships are:
cs200g2g = friedman, ablanche, jlauve, eanders8.
cs200g2r = bjacobs, evukman, schwartz, ichrist2, jregan2.
cs200g2s = dlarue, dhuo, pershing, jkachins, srawal.
You should NOT make your code world-readable---i.e., members of other groups must NOT be able to read it. Having these unix-groups will help you do that if you set the protections right. Oh... and remember, that when you log in, your group identity will NOT be one of the above, but will be your login group identity. To for the rest of your current login change group identity, if you need to, you will want to use the newgrp command (and to do so every time you log in to work on this... you cannot change your login group identity unless you are a superuser). So, one typical (although perhaps old school) way to control access/coordination/protections/etc. on the CSUG machines would be to have all the files belong to your cs200g2X group, and to use RCS (do a "man" on rcs, ci, and co, for example, to learn about these if you don't already know about them), of course setting the protections appropriately for all things (but be extra careful regarding not tripping up rcs by fiddling too much with things that rcs likes controlling).