Meeting Notes from the CalgaryDevelopersMeeting

Friday, 2 June

see also


(WPA supplicant issues)

All saw the web page on where to find the nearest Tim Horton's place. All were told about how the doughnuts are "goood" and how the sandwiches are "fiiine". Some started having doubts about the quality after learning Wendy's own this chain. all were excited to eat the best doughnuts in the world...


(more to follow)

Agenda Development

  • Agenda
  • List of Deliverables from this meeting

What Do You Want?


  • Run Viewer from a Python Console Multi-threading issues

  • Widget Services that Viewer provided in Tk --> Qt We're having to re-do some things

  • Inter-process communication issues

The Viewer gave up the event interface; it is event-driven, ideally we


The only thing that I would like to have is a coherent picture of what people like DebraShepard and SteveMeyers want delivered in order to say that this is the first phase, usable.

I think that the Viewer should be usable stand-alone, which includes

The basics of the framework are worked out

What tools are required?

Testing? A lot of bugs are going to show up unless we've tested extensively.


How is this new system going to evolve to what ALMA wanted, which is an ACS interface?

DarrellSchiebel: The CcmTools that we've developed have a binding for Python, we almost have a generator that binds to MICO, and that is getting close to a generator for ACS bindings...

Raymond: So I want to see the bigger picture; we're so focused on Python but that looks like the old system with Glish. Don't we need ACS bindings for the Pipeline?

The current setup with Python, how do you accomodate a Java-based viewer, or a FORTRAN program.

I'd like to hear from people about the tools are using. What works?


Boyd wants insight into the current status of things. The discussion so far, even,


Wants to learn about the current state of things too.


I think we need to know what exactly the bits are that we need to deliver, out with the old in with the new, that we need to deliver from ALMA.

raymond: we know what the requirements are, but the functionality is actually going backwards right now.


I represent the ScientificProgrammers -- Joe, Sanjay, George, Kumar, Urvashi --

We will need to do some refactoring in the scientific code; if there is an easy path to this

We have a lot of tests right now that are in Glish; we need to migrate that to Python, regression tests during this transition.


Stopping AIPS++ development, CasaFramework

  • Stopping Glish development, binding things to Python

  • call the Glish-based version AIPS++ -- do we do that sooner, or are we getting lots of productive stuff from other people? For example JuanUson reports on the parallactic angle.

How do we support an ANTF branch, ALMA, CASA, etc?

Working viewer in the Glish branch for reference? A: A VMWare image?

Timeline - from here to 2010

Joe's tasking thing is basically that.

What deliverables we want for Debra and Steve -- there is a bit of fluidity beyond 2008. In the next few weeks Joe is to solidify this.

Status of Framework

Comparison to Glish Tools

Glish was two things:

  1. Scripting Language
  2. Distributed-Process system, event system

CasaFramework-glish.jpgRelationship of Scripting Languages to Tools implementation

CcmTools Overview


CcmTools Demo

(have to use the same version of the compiler)

(packaging issues)



XML Tools


Very good for Java ReFactoring, source navigation,

Packaging, Distribution

Qt Licensing

We need a license for Qt support.

We may need to re-distribute Qt with the binary distro, as we depend upon a very



* Multi-threaded debugger - Sun Studio


* - Sun Studio

ACS -- ShannonJaeger

There is a telescope, optical, 1.8 m, on the outside of town. We wanted to migrate the control system from a legacy DOS-based system to an Object-Oriented control system. DaveFugate was available to help, so we went with an system based on ACS Components.


Currently, ACS Needs a static IP address.

Heuristics -- Wes

Problem is memory leaks in the pipeline, related to the creation of lots of small objects in the array libraries in the current pipeline implementation.

Lindsay is using the old prototype. We are just about ready to switch her over to the new framwork implementation.

Dirk was playing with the conflicts in the various libraries. That it removed the system's Python.

RaymondRusk: It interfered with the system's Python, with the Red Hat implementation of package management. It insists on looking for Python in /usr/lib -- it didn't set the RUNPATH correctly? Well, he was using an old version of the RPM

So are there still some RPM issues with the all-in-one RPM?

C++ Plotter Interface

  • What is the problem right now?

MatPlotLib is kind of klunky.

Most of the use cases from C++ are from what we used to have as the PgPlotter class in C++.

An example use-case is the calibrator: there are calls to the PGPlotter embedded in the calibrator.

WesYoung: We just need to abstract it out, and be able to plug in PGPLOT or MatPlotLib.

KumarGolap: As a higher-level C++ programmer, I would like to say that I have X-Y data and just plot it out.

DavidKing: What did you do in AIPS++?

KumarGolap: There was the PgPlotter class. You could do that. You could grab a region and get stuff back.

DavidKing: It was basically a seperate, Glish process, like a Viewer process. Controlled from Glish.

KumarGolapGolap: Right, so what we want right now, primarily, is a simple C++ class for plotting. Secondary we want perhaps some region selection or manipulation.

Then another thing that we were discussing was the simple-mindedness of most plotting packages: if you give it a million-point data set, it's going to attempt to plot a million points on the screen (no matter that one cannot discern a million data points on the plot).

Malta when he was doing the remote viewer for the archive, they would generate PNG files from a Java servlet because all the plotting was done on the server, right close to the data.

So -- what we want is an INTERFACE which permits the application-layer code to be plotter-agnostic: one binding would be the PgPlot class, another binding would be the MatPlotLib implementation (which would perhaps call out to a Python server asynchronously).


Where in the script that it fails, you want to know where it failed.

Has to be independent of the user code.

  • Throw an exception from C++, handle (catch or re-throw) in the Python client

  • Throw an exception in Python, so you know where a script failed -- you would be able to have a Python stack trace passed into (or through) the C++ libraries.


We want to specify a top-level handler in C++ that converts C++ exceptions to Python exceptions.

So that C++ exceptions are being handled.

Standard AipsError

  1. Severity
  2. Message

DarrellSchiebel: I think that you'd want to specify in the CcmToolsConfigurationDatabase how to insert try/catch handlers...

BoydWaters: We want to handle a language-independent case? What would CORBA do (wwcd)?

DarrellSchiebel: You can handle exceptions in CORBA.

BoydWaters: So we should look at that, and perhaps follow any design pattern that they have...

Error States versus Exception Handling

Error states -- passing along a data structure that indicates the success or failure of a method call. It does not change the flow of a program; you must explicitly check the state. Easy to implement across language and process boundaries, but very problematic to warp all of your code to always check.

Exception Handling -- changes the flow of control: stack gets unwound, data object gets propagated up the stack until it is handled. Requires language support because it changes function-call semantics.

  • Glish set a status flag.

  • Signal handlers -- SEGV, Floating-point errors, and related fun.


blah blah blah we all agree to use Doxygen


Use the AIPS++ CodingStandards.

DataArchive, rsync, friends

Getting Wedged Between End-Users and ALMA Requirements

(Joe is not yet here, and he would shorten this discussion considerably. So we defer this discussion until tomorrow.)

Regarding the status of users versus ALMA -- by the end of this year, a release of CASA to a few users inside of the NRAO. We would all like to help users, but supporting users is really hard, takes some care and lots of time. So there will be a very limited release to a few users by the end of this year. Next year, more users within NRAO. Most of the scientists inside NRAO do not use CASA. By next year, where the NRAO management will have to exert some pressure, get NRAO scientists to use CASA. 2008 is commissioning of new telescopes.

EvlaAdvisoryCommittee - it was mentioned that some outside NRAO would like to evaluate CASA outside 2007.

Do we still want to keep CASA from a community of users for another two years?

DarrellSchiebel: It seems that we have support from within ALMA; GianniRaffi and JoeScwartz. Not only are the technically sharp, they seem to be realistic and objective.


-- BoydWaters - 02 Jun 2006

  • ccmToolsBlockDiagram.jpg:
    Error: (3) can't find ccmToolsBlockDiagram.jpg in Software
Topic revision: r8 - 2006-06-09, BoydWaters
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback