Re: stuff

[Seth Teller <teller@lcs.mit.edu>]

comments follow.

Luka wrote:
> 
> 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.

great.

> 
> 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.

this would be great, but i agree, it should not be on your
critical path.  perhaps we can sign up a windows-savvy UROP
for this in spring term.

> 
> - info on graphics tools?
> 
>   do we have lab tools installed somewhere for previewing/converting:
>   - autocad (dxf,dwg,etc)
       -- see sean

>   - other cad (something called insite is used by MIT physplant IIRC)
       -- web tool, works in a browser i think

>   - unigrafix
       -- see sean -- can convert to inventor with ug2iv

>   - other usefuls? (the old tools web pages appear rather dated...)
       -- please update it as you find things.
> 
>   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 think autocad runs on athena IRIX; i'm not sure how/if
we can make it run in the lab.  have you asked adel if
we have an IRIX license for it?

> 
>   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.
> 
good.

> - 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.

yes.  please make a manifest of /d*/*.ug and let's go over
it together.

> 
>   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.)

perhaps vitaly could take this over.

> 
> - 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:

all of the following are useful comments.  peter, i would add that
we should configure cvs to email us whenever anyone commits
anything.  yes, this generates nuisance mail, but A) it keeps us
informed and B) puts pressure on people not to make tiny or
broken commits.

> 
>   - 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.

peter, can you give the group a brief tutorial about tags
during today's meeting.  a handout or email to bmg would
be good too.

> 
>   - 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.

you're way ahead of me.  yes, i've configured bmg-commits@graphics
to be all of us.

> 
>   - 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.)

again, tutorial please.

> 
> - build tool sanity
> 
>   - the compile tools on irix are cc and CC.
> 
>     DO NOT use gcc/g++ on irix, for a number of reasons.

OK.

> 
>     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

is the union of these any more powerful than either one?

> 
> - 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...]

i have no knowledge of DL*

> 
> [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)/

i don't know what aux is

> 
> - src/{FURN,SLF} overlap
> 
> - overlap
>   - BMG/BMG/*
>   - BMG/Unify/*
>   - SM/*

sigh.