Difference between revisions of "Developer Meetings/20160531"
From Slicer Wiki
(One intermediate revision by the same user not shown) | |||
Line 44: | Line 44: | ||
= Updates = | = Updates = | ||
+ | * Discussed progress at the hackfest. Considered the pure javascript dicom io and related interoperability projects. | ||
= Conclusion = | = Conclusion = | ||
+ | |||
+ | * Jc will look at issue #1 this afternoon. | ||
+ | |||
+ | * Issue #2 is related to startup time optimization. The slicer.module* style of access meant that there was a duplication of entry points and that meant extra overhead and slower performance. |
Latest revision as of 18:10, 31 May 2016
Home < Developer Meetings < 20160531
If you would like to list your topic here, create a wiki account and edit this page. |
To Discuss
Topics from Andrey, Steve, and Nicole regarding QIICR use cases that have recently broken:
1) failure to properly handle multiple dependencies: [1] - blocker for mpReview users
2) changes in slicer module imports - [2] - courtesy email from Andras below:
Begin forwarded message: From: Andras Lasso <lasso@queensu.ca> Subject: RE: Scripted modules using slicer.module* namespace need to be updated Date: May 30, 2016 at 5:39:28 PM EDT To: "'Andriy Fedorov (fedorov@bwh.harvard.edu)'" <fedorov@bwh.harvard.edu> FYI, these extensions are very likely impacted: · Reporting · PETTumorSegmentation · LongitudinalPETCT Andras
3) Mitigation of bug tracker spam:
Earlier today, a group of highlight motivated spammers manually created account on VTK and CMake issue trackers, and started to manually create 10th of issues with incomprehensible title and contents. As a proactive measure, I suggest we: * disable automatic approval of mantis account creation * allow any user with developer access to approve account request Let me know if that sound reasonable and I will share this plan with the Slicer developer list,
Updates
- Discussed progress at the hackfest. Considered the pure javascript dicom io and related interoperability projects.
Conclusion
- Jc will look at issue #1 this afternoon.
- Issue #2 is related to startup time optimization. The slicer.module* style of access meant that there was a duplication of entry points and that meant extra overhead and slower performance.