Lab Welcome

Body

Mailing List

The mailing list is cacl@lists.osu.edu.  Enroll at: https://lists.osu.edu/mailman/listinfo/cacl or send email to: <listname>-join@lists.osu.edu using that list name (cacl).

Server Access

To run software on lab machines, you’ll need a linguistics user account.

  1. If necessary, email harmon@ling with cc to schuler to give you an OSU name.# username and password.
     
  2. Email harmon@ling with cc to schuler to give you access to mulligan, dignam and deasy.
     
  3. You can now log into mulligan, dignam or deasy from any linguistics machine. This will ensure you have compatible versions of all tools required to run lab software.
     
  4. You will start out in your own linguistics directory. You should have permission to use space on home/mulproj or home/digproj or home/deasproj, but you will have to keep an eye on your disk usage, to make sure you are not using more than your fair share. You can check your usage by typing:

    du -sh *

    from the /home/digproj, /home/mulproj and /home/deasproj directories.

Code Repositories

To run the lab systems, you’ll need access to the lab project software (and developers will need to modify the source code).   To access the released (stable) lab project source code:

  1. Go to the directory where you want your copy of the modelblocks-release directory to live (we suggest your root directory).
     
  2. If you just want to read from the repository, or if you have been given developer read/write permissions for github modelblocks,  type the following:

    git clone https://github.com/modelblocks/modelblocks-release.git

    FORMERLY: If you have been given developer read/write permissions for github modelblocks, type:

    git clone https://⟨username⟩@github.com/modelblocks/modelblocks-release.git

    ...where ⟨username⟩ is replaced with your github username. It will ask for your password.

To access the internal (development) lab project source code, which is necessary for annotation:

  1. Go to the directory where you want your copy of the modelblocks-repository directory to live, which should be in the same directory as modelblocks-release (i.e. your root directory if you took our suggestion above).
     
  2. Type:

    git clone https://⟨username⟩@code.osu.edu/modelblocks/modelblocks-repository.git

    ...where ⟨username⟩ is replaced with your OSU name.# username. It will ask for your password.
     
  3. If you will be contributing to our repository, email harmon@ling with cc to schuler to add you to the compling user group.

 

NOTE: If you have a repository using the old remote location, and wish to update to the new location, type the following, then push and pull as usual.

git remote set-url origin https://⟨username⟩@code.osu.edu/modelblocks/modelblocks-repository.git

FORMERLY: If you just want to read from the repository, type the following:

git clone ssh://ling.osu.edu/home/compling/modelblocks-repository

If you have developer read/write permissions, type:

git clone ssh://⟨username⟩@ling.osu.edu/home/compling/modelblocks-repository

...where ⟨username⟩ is replaced with your ling username. It will ask for your password once. 

Tex Repositories

To contribute to papers in the lab, you’ll also need access to the lab latex repository. To access the lab latex repository:

  1. cd to the directory where you want your copy of the latex-repository directory to live.
     
  2. type:

    git clone https://⟨username⟩@code.osu.edu/modelblocks/latex-repository.git

    ...where ⟨username⟩ is replaced with your OSU name.# username. It will ask for your password once. 

If you will be using the nlp project space, please be sure to:

  1. Set your default permissions so that new files and directories that you create will be group read/writable:
    • add "umask 007" to your ".cshrc" file
  2. When you create a new directory in /project/nlp, /project/nlp03, /project/nlp04, or /scratch/nlp, you need to do two things:
    • Change the directory's group to nlp using chgrp compling
    • Set the directory's sticky bit using chmod +s
  3. Subscribe to the cacl newsgroup, to receive announcements about lab facilities: send mail to cacl-request@ling.osu.edu with subject subscribe.

If you didn't change your umask immediately, or didn't set sticky bit somewhere, you will have to:

  1. run chmod -R 770 on all your group-unreadable files and directories
  2. run chgrp -R compling on all your group-unreadable files
  3. run chmod +s on all your group-unreadable directories to set the sticky bit that controls group inheritance

Git workflows for developers

  1. Clone the directory as above.
  2. Create a .gitconfig file in your home directory to contain personal information as well as handy aliases (you may copy and paste the following directly, adding of course your real information):
    [user]
            name = (your name)
            email = (your email)
    [alias]
            co = checkout
            ci = commit
            st = status
    
  3. git checkout -b <local_branch> ## creates local branch and switches to it
  4. vi file1.cpp ## Edit some files
  5. vi file2.cpp ## Edit some files
  6. git status ## Examine file status
  7. git add <new_file> ## If you've created new files, tell git about them
  8. git commit -a ## Commit your changes to your local branch.  You have to type a message to tell us what you did in this commit.
  9. At this point you'd like to check if someone has made changes to the main development branch, and if so integrate them with your changes to make sure nothing is broken.
  10. git checkout master ## Switch back to master branch
  11. git pull ## Get changes from the remote server
  12. git rebase master <local_branch> ## `Rewind' the changes in your branch, apply the remote changes to the branch point, then apply your changes on top of that. Also will check out the local branch for you.
  13. You can go back to step 4 now and resume development.

At some point you may want to send your changes to the server:

  1. Run steps 8-12 above so that your branch is up-to-date
  2. git checkout master ## Check out master branch
  3. git merge <local_branch> ## Merge your branch into master
  4. git push ## Send your changes to the server

Helpful tip(s):

  • The git help pages are very useful: try git help <command name>
  • git stash is useful if you need to temporarily hide some changes when you get sidetracked by other tasks. You can use git stash list to see the stack of stashes you've created, and git stash pop to apply the most recent stash and remove it from the stack.