> Any chance you could characterize the 'lousy' bits. The devil is in > the details here and I can't fix what I don't know about. If you look > through the reports you can see what other people encountered as well > but more information would be helpful here. > "Lousy" --- when I cut and pasted any text with a TAB embedded in it (ie, cb.setdata() # Comment) the TAB would somehow prompt cb., and I would get the full list of things that could be done --- or SOMETHING like that. ALSO, if there was a leading space, " cb.setdata()", that would cause problems (oh, you addressed that). And finally, the use of the white space (or something) would result in casapy getting confused (or me getting confused about exactly what state casapy was in), and I'd have to bail on casapy and restart. SO, I was learning how to walk the straight and narrow. Now that I know the straight & narrow, I can't make casapy fail quite the same way! > Notes in the Report. > > -Mark > > > > Misc notes: > > > OK, blank space in the scripts gets you into MAJOR TROUBLE when > cutting and pasting. spaces preceeding a value command result in > that command being invalid: > > CASA [260]: i = 2 > > CASA [261]: i = 2 > ------------------------------------------------------------ > File "", line 1 > i = 2 > ^ > SyntaxError: invalid syntax > > > Welcome to the world of Python. This is a Python language issue and > not something that we can alter as long as ALMA is using this language. > > ALSO, tabs in your provided example script get misinterpreted > as "tell me more about this tool (ie, tb.) > > > I don't quite understand this. does some sensible 'completion'. > It will do file completion on a partial name or it will give you > information on all methods that are available in a tool, etc. What was > the issue. > The issue, as stated above, was that when cutting and pasting from the example python script where a TAB was imbedded between the command and the comment, I was getting wild completion in a context which I did not think was sensible. > It seems that you can't have two tables open at the > same time? Or images or MS? BIG MISTAKE if true. > > > Don't worry, it's not true. We offer by default a single instance of a > tool as this will limit and potentially eradicate the concept of > constructors for most astronomers that don't want to handle it. > Additional tools of any type can be created with a 'create' invocation > - I didn't advertise this as I didn't think it was necessary for this > test. > Good. You are right, it wasn't necessary for the test. > Hey, I got into a space where mp.close() (or mp.anything) > results in: File "", line 1 > mp.array() > > > This is puzzling and hasn't been replicated elsewhere. I'd like to > hunt this down if you can help me reproduce it. Is it just the > scriptlet that you provided - if so, I'll look at it. > I probably can't reproduce this. - Show quoted text - > > I solved for type='G' with cb ("crunchberry beast?"), and > LOW AND BEHOLD it found some good solutions in spite of only > having a single baseline! > > > Overall feeling is that this is a more > straightforward interface than the old AIPS++/glish, > although I am sort of hamstrung in that I don't know how to > do manipulative mathamatics in Python > > Potentially major problem: > tb.open('3C273_0506.ms') > dat = tb.getcol('DATA') > t = tb.getcol('TIME') > i = 3 > t[i+1] - t[i] # === ok, this works now, but it often DID NOT work. > ## and I can't figure out how to do vector operations on t, dat, > which > ## seem to be lists??? > dt = t[1:64] - t [0:63] ## how do I get a vector of dt? > > > Two issues here: > First tables was incomplete and not advertised for this test as it > hadn't been fully implemented either in functionality or robustness. > The return of lists is a design decision however as it allows the user > maximum flexibility in handling the output data. 'lists' are readily > converted into arrays, vectors, etc through the use of the standard > Python mathematical libraries (numarray, numeric, soon scipy). Keeping > them as lists allows one to use your favorite lib - based on what I've > seen in the community, things should collapse soon on the scipy. > OK -- next time I use casapy and I need to learn how to convert, I'll be calling! > Overall feeling is that this is a more > straightforward interface than the old AIPS++/glish, > although I am sort of hamstrung in that I don't know how to > do manipulative mathamatics in Python > > On a number of occasions, casapy got into a bad state, > and things that should have worked did not -- restarting > casapy usually fixed things. > > > This shouldn't be necessary and wasn't seen elsewhere - I'd really > like to better characterize the 'bad state'. > Debra ran into an issue with the 'mp' tool in which it stopped > handling flags until it was re-initialized (by loading another data > set); was it something like this? > I remember typing several commands, trying to plot, trying to do anything, and it was like I had entered a different level (like if I was in help and couldn't get out, only that wasn't it). It was like being in a NIGHTMARE and not being able to wake up, until I found CNTRL-C.