frameworks
- Train Thoughts (Mon Aug 12 22:22:28 1996)
- CDF uses (and will continue to use) analysis_control as the framework for
both online and offline. The advantage is the development environment is the
same online and offline. Mail to Jan H.
- It would be nice if RCP parameters could be set from the command line. If
they are changed and a module does not re-read them, a warning should be
printed.
- A way better error recording utility is needed, mate. Stats. Etc.
- Extra Link Files (Wed Aug 14 00:11:13 1996)
Make it simple to add extra link files/libraries. For example, if someone
changes an offline object, it may require rebuilding a good deal of code to
match it -- these would all be extra .obj files that there is no way the user
would want to include -- so make sure there is a way for them to make it into
the link.
- Potential problem with the single file is a RCP guy (Wed Aug 14 19:37:09 1996)
There is a possible problem with the massive RCP file we have been thinking of.
Namely, if the RCP file is built by the program builder, not the linker, what
if they relink after an update of the libraries w/o running the program
builder? If the RCPs have been updated, the new version of the RCP won't be in
the RCP file.
- D0_Event Object Started (Thu Aug 15 15:48:18 1996)
Started building a D0_Event object along the lines of what Scott has in
D0_Event.py so that we can get these two guys to work together. Found some
interesting stuff along the way.
- D0_Event.h has been created in the frameworks/source area.
- Simpler than I remember accessing this stuff.
- Might add default constructors to d0argument_list that will handle single
arguments to make argument building simpler.
- d0argument_list should bomb if you try to do arg[1] and there isn't one.
- Is there a way to make sure that the script object passed to D0_Event is
really a D0_Event object?
- Exceptions: when we call handle and there is no data (or call gotdata
twice), how is that pushed back into gcc?
- What should we use as the C++ string?
- What the hell is a data handle (holds ref to zebra, dspack, etc.).
- Getting the type of an object (Thu Aug 15 21:57:32 1996)
It might be worth while adding an "type" method to the generic script object
that will tell you the type name of the object (string, int, etc.) -- but it
would be problematic, as things like tcl do everything in strings.
- Scripts and RCP (Mon Aug 19 14:27:20 1996)
- It should be possible to have a script as part of a command file, much as
it is now in DCL with compak.
- RCP parameters should be able to be class variabled. For example:
rcp_var<int> my_butt (<rcp-name>, <rcp-bank>, <default_value>);
- Comments on Java (Mon Aug 19 14:51:01 1996)
I've been looking at Java to see if it is any good for what we need.
- There seems to be an interface for calling from java to a C method (there
is a tutorial at the
javasoft web site).
- In Java any object with a native method must be decalred as such, in
Python this is transparent. So, in python the object defs are the same, and in
java that isn't the case.
- Can you dynamically load and run a java script, or does everything have to
be compiled now (even your command files!).
- Interface specification isn't dynamic in Java. The methods must be
declared in source code. In Python, the methods can be determined by accessing
the language structures, and it is possible to add callbacks as the program
progresses.
- Every java DK will have a different way of doing this (COM/SOM/dlls, etc.)
- Is it clear that this stuff will really be around in 10 years? At least,
with Python, we have
the source code. MS really doesn't like it.
- Cost?
- Lots of bugs. Reading the newsgroups gives one the impression that it
really isn't ready for primetime yet.
- Will its security features get in the way of what we want to do?
- ILOG is working on some tools to map
their C++ libraries into Java (some example code
by a fellow that works for ILOG.
- Garbage collector works not by keeping track of references, but pointers.
It is automatic, but less flexable (can keep global vars around in python that
you can't in Java).
- Java has a much better thread/sync. model than does the current version of
Python.
- java vars are hardcoded (Mon Aug 19 18:18:59 1996)
java varriables are are accessed by building a struct with the javah compiler,
which produces a struct def in a .h file which must be included in the C
program. This means:
- Change/add a varriable, must rebuild the whole thing.
- Can't build/access objects on the fly.
- On the other hand, it looks like it is possible to do method/procedures by
name.
- But you must know a head of time what is static and what isn't.
- Java must be the over-all program (as Python is in the current design).
- More on the previous entry (Mon Aug 19 18:26:28 1996)
This would mean the way we do Get and Set on the various instance vars would
break (as it uses character strings). The java way would be a lot closer to
the c++ form of programming. That would be good. I'll assume that subclassed
objects behave correctly. Also, it dosen't look like it would be possible to
have the automatic dispatch -- it looks like you have to define a callback
entry point for every single method you declare. Something else I wanted to
avoid (proliferation of non-c++ objects and files; will be a mess).
- Meeting with Scott (Fri Sep 6 05:41:01 1996)
Met with scott for about 4 hours and discovered a number of things.
- Adopt his package naming convention. A package is named by its class name
(like jetMaker) and its main RCP file. The d0 package will provide access to a
routine that will generate a C++ object inited with a given rcp file. This is
a change from the scheme used by us both right now.
- Discovered that Python doesn't have callbacks for object creation -- so
you can't create a C++ object when you do a new to python. One might be able
to fool it by generating a generic type object (object type) that has a
callback to get the __init__ attribute. The __init__ attribute would create a
new object, build the c++ object, and then pull a fast one a fool the Python
interp into thinking that was the one it just built. However, this is pretty
unpleasent, and probably would break pretty quickly.
- We will have more than one instance of a package with the same RCP file.
This is needed as we will be having several packages active at once (split
event paths).
- Parallel event paths will be made to work. Perhaps multithreading as
well.
- Scott almost has a UI section working that allows the rest of Python to
work at the same time. I've heard rumors that Dhiman is going to work on
making the UI real.
- We went round and round on RCP files.
- Main rcp file is supplied during package creation.
- Allow python (UI, command line, input file) to change the default
settings.
- Nice to have the ability to change RCP parameters in the middle of the run
- How to notify packages that RCP parameters have changed (what if they
calculate new values based on the RCP parameters). Several schemes work; none
perfect.
- Should we allow a package to read in more than one RCP file? Should it be
allowed to explicitly read in a RCP file?
- Only a package should have access to base RCP files? Subroutines, etc.
can access them, but they can't read in stuff?
- Big list of things to do still.
- Get package instantiation going in C++ and Python.
- UI
- Program Builder
- Old package converter (Reco stuff).
- RCP interface
- Improvements to the I/O package (Scott -- filenames, etc.)
- Filenameing package, UI package, etc.
- RCP Tricks (Wed Oct 16 21:04:31 1996)
Some other features that might be nice to see in RCP files
- For packages calling packages, with an RCP name, allow the caller,
somehow, to modify the default RCP. Only, the user may want to override the
defaults, and it is that changed default copy that should be changed further
changed and passed to the called package.
- One one RCP per package?
- Joint Cal OO and Frame Meeting (Thu Oct 17 19:51:33 1996)
There was a joint meeting between the cal oo group and the frameworks group
yesterday. It seems there are some differences (in extreems along the same
scale) between the two of us.
- More than one data stream through the dude (more than one open)
- They talk abouthaving the user write the main program, us the other way
around.
- Objects that do the work don't know about RCPs for them.
- Objects know how to build the subobjects they need; instead of leting the
user sub in different packages.
- Added D0_Event and process_event (Fri Dec 6 00:04:30 1996)
There is now a process event method that gets an honest to goodness d0_event
object. I've updated my tests as well.
Last Update: Fri Dec 6 09:29:30 1996