{5} Assigned, Active Tickets by Owner (Full Description) (10 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
dshipton
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1 | Migrate old wiki to trac site | website | defect | 01/16/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Must migrate old wiki from http://oldsite.vrjuggler.org to the developer trac site |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
patrick
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #36 | PyJuggler does not work with Cocoa | PyJuggler | defect | 05/11/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When built on Mac OS X with Cocoa, PyJuggler does not behave correctly because the Python script that is the application gets interpreted as a document. VRJBasicDelegate (or VrjApplicationController as it is currently known on the VR Juggler 2.2 branch) then tries to load the Python script as a VR Juggler configuration file, and this of course results in a fatal error. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #12 | vpr::Singleton<T> does not work across DLLs | VPR | defect | 03/15/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I have verified that the class vpr::Singleton<T> does not work correctly for creating a singleton object that is consistent across DLLs on Windows. I suspect that the same is true for .dylib files on Mac OS X. The symptom is that a singleton accessed from two different DLLs has two different memory addresses, and as such, is not a singleton. I don't know this for sure, but I suspect that the fact that the singleton interface is inherited from a templated type has something to do with the problem. All the template member functions are inlined into the calling code, and this may create some sort of weirdness with DLLs. By changing a given class to use the macros vprSingletonHeader() and vprSingletonImp() instead of deriving from vpr::Singleton<T>, the memory address issues go away. Perhaps some refactoring of vpr::Singleton<T> could make it more DLL-friendly. Certainly, there must be some references on ways to make something like this work. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #17 | Multiple singleton objects with static linking | VR Juggler | defect | 03/15/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I have run into some strange behavior wherein two different instances of the same singleton class are created when using static linking. In this case, I was testing jccl::ConfigManager, and two distinct pointer values were being returned by jccl::ConfigManager::instance(). I do not know what would cause this, but I suspect that there is probably a compiler or linker flag that would fix the problem. That's usually what ends up being the fix. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #27 | vrjconfig.bat can build up a command line that is too long | VRJConfig | defect | 03/15/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The way that vrjconfig.bat works is quite different than its shell script counterpart on non-Windows platforms. The command line that gets executed by vrjconfig.bat can become quite long because the entire Java class path is set as an argument to the java executable. Depending on where VR Juggler is installed, the path can end up being too long. This can probably be worked around by setting the CLASSPATH environment variable instead of setting it as a command line argument. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #35 | Add exception translation to PyJuggler 1.1 and 1.3 | PyJuggler | task | 05/10/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PyJuggler needs to be told about exceptions derived from vpr::Exception that may be thrown by C++ code. There should also be some rudimentary conversion of Python exceptions to Juggler exceptions in certain places to allow the Python code to report errors to the C++ code. This has to happen before the PyJuggler 1.2 release. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4 | Profiled build fails on the trunk | Build System | defect | 02/21/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The profiled build on the trunk is currently failing. I believe that this is due to a problem with the flagpoll .fpc files or the use of said files in setting up parameters for the profiled build. Diagnosing the problem will require more investigation, but it should not be hard to fix once the problem is identified. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #37 | VRJConfig should save symbolic enmeration values | VRJConfig | 2.2 | defect | 06/06/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When VRJConfig saves config elements that have properties where enumerated values are defined, the symbolic value should be saved instead of the literal value. This will make configurations more robust and easier to read. This same problem existed a long time ago with VjControl, but it was easy to fix. One hopes that it will be similarly easy to fix with VRJConfig. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10 | Sim UDP sockets cannot be connected | VPR | defect | 03/15/07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
At the OS level, calling connect(2) on a datagram (UDP) socket sets a default destination for all messages. In the VPR sim sockets, connect() in the Socket Manager only works for TCP sim sockets. This needs to be corrected. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3 | Add support for Cocoa on Mac OS X | VR Juggler | 3.0 | task | 02/14/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Since the VR Juggler 2.0 beta days, I have been planning to add Cocoa support to VR Juggler to drop the need for running an X server. Doing so means using Objective-C and Objective-C++. The build already supports these two languages, and I have had most of the Cocoa written for a while. The big hurdle has been working out the multi-threading issues in the context of Cocoa, of which there are many. At this point, I think I have most of the big problems solved. The only remaining issue known to me at this point is how to prevent any windows from being opened from the kernel control loop thread before the primordial thread enters the Cocoa run loop. It may be possible to graft data (most likely an NSConditionLock) onto the global NSApp object using features of Objective-C. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
