This afternoon you will try out the tools needed for the project,
and start working on it. Since we are going to have a long period
of time without classes, this session is particularly important:
you will need to be independent and work alone (or with your group
partner) in the following four weeks.
Of course I will answer questions in the next few weeks: you can
write to the mailing list, so I will answer publicly, or come see
me in my office.
Please don't ask me again what the project is all about: there's a whole page about it, I have explained it again in the mailing list (even in French), and I've spoken about it in class today.
When you work at the Institut Galilée labs, before starting, you have to execute the following line on every terminal you use:
source ~10706282/add-prefix ~10706282/usr
Of course you don't need to do anything similar at home if you have installed everything correctly, because you are the administrator of your own machines.
You can find some practical suggestions at the bottom of the first TP page.
If for some crazy reason you are not subscribed to the mailing list yet,
please do it now.
Use the web interface linked above; it's easy and you shouldn't need my assistance.
A student noticed that the page may ask you to
accept certificates. Don't worry, the server is at LIPN, Université Paris
13; it's safe.
You already know how to use Guile at this point. Today you have to learn how to use bzr and Bugzilla.
Create and enter the directory where you want to create your working directory. Let's call ~/dll the directory where you want to create your working directory (your working directory, with bzr, is also a local repository and a local branch (if you don't understand this then you should read this page)):
mkdir ~/dll-stuff
cd ~/dll-sfuffThen, from that directory, get a copy of the current project sources:
bzr branch[not available any longer] Look at what you got:
lsThe new directory you see is your working directory, or local repository. Enter it:
cd dllModify one file in the project directory, and save it. Then look at what changed compared to the version you downloaded:
bzr diffThe output of bzr diff is something you could send to the mailing list to show your modifications. You should be able to undersand it, at least intuitively. Do other file modifications, and then run again
bzr diffso that you can understand the patch format. After you are satisfied that you understand the patch format, cancel your changes and go back to the version you downloaded by typing
bzr revert
If I did some modifications in the central repository, you could apply them to your local copy by typing
bzr pullTry the line above; this time it will say that there were no changes to pull because I made no changes, but of course this will not always be true.
The bzr commands above are the bare minimum you need to work on the project. The bzr documentation linked from the project page explains all of this and much more.
From now on I will often only mention the bzr command names you need, without the specific command lines.
Make a local branch from your working directory into a new directory, on your computer You need bzr branch (use
bzr branch --helpto get some information). In your local branch, make some modifications and save them. Make a new text file in the branch containing some lines, save it then add it to the branch (use the command bzr add to let bzr know about the file: by default a file does not belong to a repository ;
bzr add --helpto get help). Ensure that your new file is in the branch. From the branch directory:
bzr diffYou should see your file content in the output of bzr diff. If everything went smooth then commit your changes in the branch by entering the branch directory and running
bzr commitAn editor will be opened, for you to write a descriptive commentary explaining your modifications. Write something, and save. If everything worked now you have committed your changes in the branch.
Enter your working directory:
cd ~/dll-stuffPull the changed you made from your local branch to your working directory, with the command bzr pull (you need an option: of course you get help about that command with the line
bzr pull --help).
You don't really want the changes from the branch in your working directory: undo the changes, by using bzr revert with a parameter (the parameter you need to supply is a revision number: you get help with the line
bzr revert --help). If you can't do this, then at least delete your working directory, and re-create it with the first bzr branch command line we used above.
If everything worked well, now your working directory contains a copy of the central repository.
Bugzilla is a bug database with a simple web interface; there isn't much to learn but you have to play with it a little, and get confidence. Our Bugzilla installation is here on my server.
Subscribe to out bugzilla installation, so that you can report bugs. Notice that the username requested by bugzilla is an email account. You will probably need to open the automatic message the system sends you to confirm your membership. The email address you use may get some spam, so don't use a valuable address. The system may be a little slow when sending mail. Don't worry, that's normal.
You don't have access to the "Administration" part, but that's normal: you don't need it. You just need to be a normal user in order to report bugs.
File a dummy bug with your new account, just for
testing, in the DummyProcuct product.
Write the string "dummy" somewhere in the summary field,
so that it's easy to see that the bug is not real; please also
write the name and surname of all the people in your group
(maximum two people) in the description field. I want
to see a dummy bug per group.
Play with the other fields, so that you understand more or less what they are for.
Confirm by hitting the Submit Bug button. The
system will send an automatic e-mail message to the mailing list
when a bug is created.
The system may be a little slow when sending mail. Don't worry, that's normal.
You will notice that your new bug has been assigned a new unique
number. We will use such numbers to unambiguously identify (real)
bugs. Nice, isn't it?
Now close your dummy bug by marking it "invalid". Another message will be sent.
Look at the existing bugs, and at the Bugzilla search facilities. Try some search queries; search for your bug. In your opinion why is it still there, even if it you closed it?
Use the mailing list for communicating (yes, even if I am in the lab: it's useful to have a permanent public record that everybody can see even if working from home) and sending your code.
At the end of the session some good group should have finished some turtle graphic primitives.
Multiplicative bonus on the final mark for the first group sending some useful nontrivial (and correct) code for the project to the list. Of course every piece of code, documentation or useful constructive discussion you send to the mailing list will be evaluated and contribute to your final mark, but this is an extra incentive for the first good group doing something good.
During the following weeks you'll have to work alone. This is a good time for asking me questions.
You don't need to be formal when writing on the mailing list (and you can use French in the mailing list messages). You can brag if you do something good, and playfully taunt your colleagues. Show off what you do. Many free software hackers have a big ego and I'm certainly no exception, so I won't get impressed if you have an high opinion of yourself. Impress me with your code instead.