stuff

[Luka <luka@MIT.EDU>]

yes, T/4 meeting time is good for me.
i'm in the lab on tuesdays/thursdays for the remainder of january
(and other days perhaps, but those are not scheduled yet).

here's some random thoughts based on where i am with the code.

basically, the walkthru code is still a mess but i am working on
cleaning it up.  i think that needs to be top priority for me and
hopefully i can finish it off in another week, or at latest by the
end of the month.  til then, realize that the tree is subject to
massive rearrangement and don't get too comfy.  if anyone is doing
active development against code in the module /d9/project/walkthru
right now, please please PLEASE tell me right away exactly which
parts are relevant to you so we can coordinate as needed.

more notes on the state of the tree at bottom of this email,
if you care (and some of you might).

otherwise, various general things of interest to lots of people:

- anyone want to maintain windows?

  apparently the walkthru stuff is all buildable for windows, which
  is nice.  however, frankly, windows scares the bejeezus out of me
  and i try not to touch it.  so i'll try and be reasonable when
  making code changes and not *blatantly* break windows compat, but
  i'm not intending to actually grok/build/test windows myself.  if
  someone else in this crowd loves windows devel more than i do, i
  encourage you to raise your hand and i will gladly help you get up
  and running with that independently.  the goals if someone does
  this should be to:

    a) figure out the current build process for windows and document
       it clearly in one place.
    b) ideally, create a 1 step automated build + test process.
       that way even someone like me can log in to windows, type one
       command, and at least see as a binary result whether changes
       in cvs break the windows build or not, without having to get
       more intimately involved.

- info on graphics tools?

  do we have lab tools installed somewhere for previewing/converting:
  - autocad (dxf,dwg,etc)
  - other cad (something called insite is used by MIT physplant IIRC)
  - unigrafix
  - other usefuls? (the old tools web pages appear rather dated...)

  i know we have autocad somewhere, but don't know where.  also, that
  may just be for windows in which case having at least a basic viewer
  that runs on unix would be convenient.

  i have some of my own tools i like for these purposes also, but i
  want to know if there are lab tools existant first, and then
  suggest/do further installs iff that's still useful.

- mit data files.

  we need to figure out where/what all our data files are.  there is
  way too much redundancy/hacking scattered around, and organization
  is paramount when even the ideal dataset is inherently enormous.

  seth, think we should do a run over the disks like we did for the
  walkthru code trees?  this is also something that could be tasked
  onto someone else if it proves hairy enough, or someone else just
  has time for it.  (it would be fine parallel work while i'm still
  hacking the code this week.)

- cvs sanity

  i'm sure you'll hear more about this from me in the future, since i'm
  pretty amazed at the poor way the cvs tree has been maintained and
  would like to take some preventive measures to keep it from ending up
  this way again.  notably, if you're going to be working in the
  walkthru module and don't fully grok cvs at any time, feel free to
  ask me for help.  it's well worth my time teaching you now to prevent
  difficulties later down the line.  some general notes for now:

  - if it does not compile, do not commit it to the main line.  period!

  - if it is valuable and versionable, put it in cvs, not just in your
    local sandbox for us to hunt for after you leave.

  - if it is valuable and versionable but does not compile, You Might
    Need A Branch!  so make a branch.  publish branch names to this
    list so others know how to find them should they need to.

  - tags are useful.  learn how to use them.  if you're publishing a
    paper based on some version of code under walkthru, i expect to
    see a tag for it.  i also expect NOT to see a 'cp -r' of a huge
    chunk of the code into walkthru/My_Thesis/, unless you're actively
    trying to test my patience.

  - i should configure a cvs commit mail script, probably to go to a
    list like walkthru-commits or bmg-commits...  that will happen
    sometime, after i've finished more of the large-scale cleanup first
    i think.

  - we're in a position where we could reasonably and thus probably
    should re-export the entire walkthru module at some point.  i think
    this should happen in maybe 2 weeks to a month from now, after the
    big cleanup i'm doing is done, after some amount of independent
    checkout and testing has happened, and before new major development
    begins.

    til then, start using -P regularly, and fixing dirs incorrectly
    lost, because they will get lost for real once a re-export happens.
    (i've been fixing these as i go through the tree presently.)

- build tool sanity

  - the compile tools on irix are cc and CC.

    DO NOT use gcc/g++ on irix, for a number of reasons.

    if you did not previously realize that .o's compiled with CC and g++
    will not safely link against each other, you do now.  (yes, there's
    recent stuff in the tree that prompts this comment.)

  - do use gmake.  not pmake, not smake, not my_favorite_weird_make.
    gmake provides a full feature set with well-defined syntax, and is
    available on every platform.  the conclusion is obvious.

ok, that's it for fully general interest for now i think.  here's a dump
of the remainder of my current notes on redundancy in the walkthru tree.
some of these i am still going to clean up and some i am leaving, as
noted.  vitaly and seth at least probably should read below here.

- 2 indep ug2iv impls. (yes, 1 is a clean re-impl.)  reconcile and rm one.
  [for now i'm not touching these.  already rm'd all redundant copies.]
  - mit/src/ug2iv
  - util/ug2iv

- GetFiles stuff
  [since it sounds like vitaly may be taking this, i'm leaving it.  but
   here's a list of the heap i've got so far for your reference.  all
   these should get purged and replaced with a simple script that is API
   compatible with the old stuff, i think.]
  - URL
  - BMG/GetFiles
  - mit/src/GetFiles
  - {BMG/end_to_end,mit/src}/documentation/DL*
  - (note 2 apis: GetFiles and DLFiles, on top of ReadURL api(s).)

  [and yes, that really is the typical level of replication i've been
  dealing with cleaning up on EVERYTHING.  Yeesh...]

[you guys really don't care about the stuff below.  i'm just dumping the
 rest of my current notes here on the off chance that  someone says "aha!"
 on seeing it and gives useful feedback on what to do with the stuff below
 before i have figured it out myself.]

- 2 copies of libforms checked in
  - BMG/lib/forms
  - sims/impulse/forms

- BMG/end_to_end
  - vs. mit/aux(/acad2ug_layers)/
  - vs. mit/bin(/acad2ug_layers)/

- src/{FURN,SLF} overlap

- overlap
  - BMG/BMG/*
  - BMG/Unify/*
  - SM/*