You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(4) 
_{Dec}
(6) 

2002 
_{Jan}
(68) 
_{Feb}
(72) 
_{Mar}
(46) 
_{Apr}
(44) 
_{May}
(40) 
_{Jun}
(54) 
_{Jul}
(26) 
_{Aug}
(86) 
_{Sep}
(95) 
_{Oct}
(151) 
_{Nov}
(65) 
_{Dec}
(34) 
2003 
_{Jan}
(22) 
_{Feb}
(70) 
_{Mar}
(24) 
_{Apr}
(28) 
_{May}
(50) 
_{Jun}
(31) 
_{Jul}
(17) 
_{Aug}
(42) 
_{Sep}
(27) 
_{Oct}
(71) 
_{Nov}
(27) 
_{Dec}
(71) 
2004 
_{Jan}
(40) 
_{Feb}
(30) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(41) 
_{Jun}
(9) 
_{Jul}
(24) 
_{Aug}
(41) 
_{Sep}
(35) 
_{Oct}
(8) 
_{Nov}
(5) 
_{Dec}
(4) 
2005 
_{Jan}
(27) 
_{Feb}
(13) 
_{Mar}
(18) 
_{Apr}
(7) 
_{May}
(10) 
_{Jun}
(36) 
_{Jul}
(28) 
_{Aug}
(17) 
_{Sep}
(1) 
_{Oct}
(11) 
_{Nov}
(12) 
_{Dec}
(15) 
2006 
_{Jan}
(99) 
_{Feb}
(5) 
_{Mar}
(31) 
_{Apr}
(26) 
_{May}
(20) 
_{Jun}
(33) 
_{Jul}
(45) 
_{Aug}
(18) 
_{Sep}
(2) 
_{Oct}
(19) 
_{Nov}
(3) 
_{Dec}
(8) 
2007 
_{Jan}
(1) 
_{Feb}
(15) 
_{Mar}
(20) 
_{Apr}

_{May}
(4) 
_{Jun}
(6) 
_{Jul}
(11) 
_{Aug}
(11) 
_{Sep}
(11) 
_{Oct}
(19) 
_{Nov}
(25) 
_{Dec}
(46) 
2008 
_{Jan}
(42) 
_{Feb}
(20) 
_{Mar}
(43) 
_{Apr}
(24) 
_{May}
(4) 
_{Jun}

_{Jul}
(19) 
_{Aug}
(63) 
_{Sep}
(33) 
_{Oct}
(17) 
_{Nov}
(36) 
_{Dec}
(20) 
2009 
_{Jan}
(36) 
_{Feb}
(18) 
_{Mar}
(144) 
_{Apr}
(36) 
_{May}
(11) 
_{Jun}
(7) 
_{Jul}
(8) 
_{Aug}
(21) 
_{Sep}
(33) 
_{Oct}
(7) 
_{Nov}
(2) 
_{Dec}
(1) 
2010 
_{Jan}
(33) 
_{Feb}
(3) 
_{Mar}
(34) 
_{Apr}
(2) 
_{May}
(1) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(28) 
_{Sep}
(8) 
_{Oct}
(12) 
_{Nov}
(11) 
_{Dec}
(44) 
2011 
_{Jan}
(30) 
_{Feb}
(10) 
_{Mar}
(8) 
_{Apr}
(23) 
_{May}
(8) 
_{Jun}
(9) 
_{Jul}
(3) 
_{Aug}
(9) 
_{Sep}
(5) 
_{Oct}
(9) 
_{Nov}
(11) 
_{Dec}
(24) 
2012 
_{Jan}
(6) 
_{Feb}
(32) 
_{Mar}
(8) 
_{Apr}
(26) 
_{May}
(13) 
_{Jun}
(51) 
_{Jul}
(21) 
_{Aug}
(7) 
_{Sep}
(9) 
_{Oct}
(13) 
_{Nov}
(5) 
_{Dec}
(10) 
2013 
_{Jan}
(56) 
_{Feb}
(6) 
_{Mar}
(15) 
_{Apr}
(4) 
_{May}
(24) 
_{Jun}
(4) 
_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(1) 
_{Dec}
(8) 
2014 
_{Jan}
(7) 
_{Feb}

_{Mar}

_{Apr}

_{May}
(12) 
_{Jun}
(3) 
_{Jul}
(7) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(19) 
2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(1) 
3

4

5

6

7

8

9
(1) 
10

11

12

13

14

15
(3) 
16

17

18

19

20

21

22

23

24

25

26

27

28

29

30


From: Matt McCormick <matt.mccormick@ki...>  20121115 16:34:14

On Thu, Nov 15, 2012 at 4:33 PM, Johnson, Hans J <hansjohnson@...> wrote: > that sounds like a great plan. +1 Thanks, Matt > > Hans > > ================================================================= > Hans J. Johnson, Ph.D. > Assistant Professor, Department of Psychiatry > > Mailing Address: > W274 GH Email: hansjohnson@... > 200 Hawkins Drive Phone: (319) 353 8587 > The University of Iowa > Iowa City, IA 52242 > > From: Peter Vanroose <peter_vanroose@...> > ReplyTo: Peter Vanroose <peter_y@...> > Date: Thursday, November 15, 2012 10:22 AM > To: "\"Matt McCormick\"" <matt.mccormick@...> > Cc: "\"Philip Tresadern\"" <Philip.Tresadern@...>, Hans Johnson > <hansjohnson@...>, Bill Lorensen <bill.lorensen@...>, vxl > maintainers <vxlmaintainers@...> > Subject: Re: API change of vnl_math to namespace > > There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; > I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* > #defines. > Currently, these backward compatibility defines are unconditionally visible. > > Objections? > >  Peter. > > > > > Matt McCormick <matt.mccormick@...> wrote: > > A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the > CMakeLists.txt: > > option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." > OFF) > mark_as_advanced(VXL_LEGACY_REMOVE) > > In core/vxl_config.h.in > > #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ > > and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". > > On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern > <Philip.Tresadern@...> wrote: >> I can confirm that adding the following macros directly to vnl_math.h work >> (at least under Visual Studio 2005): >> >> #define vnl_math_isnan vnl_math::isnan >> #define vnl_math_isinf vnl_math::isinf >> #define vnl_math_isfinite vnl_math::isfinite >> #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven >> #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup >> #define vnl_math_rnd vnl_math::rnd >> #define vnl_math_floor vnl_math::floor >> #define vnl_math_ceil vnl_math::ceil >> #define vnl_math_abs vnl_math::abs >> #define vnl_math_max vnl_math::max >> #define vnl_math_min vnl_math::min >> #define vnl_math_sqr vnl_math::sqr >> #define vnl_math_cube vnl_math::cube >> #define vnl_math_sgn vnl_math::sgn >> #define vnl_math_sgn0 vnl_math::sgn0 >> #define vnl_math_squared_magnitude vnl_math::squared_magnitude >> #define vnl_math_cuberoot vnl_math::cuberoot >> #define vnl_math_hypot vnl_math::hypot >> >> If the aim is to minimize disruption, this would be my recommendation; if > the aim is to persuade all users to migrate to the namespace version, > however, then an '#if legacy' or separate include file might give them the > nudge they require. >> >> Phil. >> >>> Original Message >>> From: Peter Vanroose [mailto:peter_vanroose@...] >>> Sent: 14 November 2012 08:27 >>> To: Matt McCormick; Johnson, Hans J >>> Cc: vxlusers@...; Bill Lorensen; ITK >>> Subject: Re: [Vxlusers] API change of vnl_math to namespace >>> >>> >>> >>> Matt McCormick wrote: >>> > Would it be possible to get backwardscompatibility macros like >>> > #define vnl_math_abs vnl_math::abs ? >>> >>> Yes, of course. Good idea. >>> I suppose this can go in core/vnl_math.h Or would a kind of "#if >>> legacy..." >>> switch be the preferred way? Or maybe a separate include file, say >>> vnl_math_oldstyle.h ? >>> >>>  Peter. > > > > > > > > >  > > > ________________________________ > Notice: This UI Health Care email (including attachments) is covered by the > Electronic Communications Privacy Act, 18 U.S.C. 25102521, is confidential > and may be legally privileged. If you are not the intended recipient, you > are hereby notified that any retention, dissemination, distribution, or > copying of this communication is strictly prohibited. Please reply to the > sender that you have received the message in error, then delete it. Thank > you. > ________________________________ 
From: Johnson, Hans J <hansjohnson@ui...>  20121115 16:33:27

that sounds like a great plan. Hans ================================================================= Hans J. Johnson, Ph.D. Assistant Professor, Department of Psychiatry Mailing Address: W274 GH Email: hansjohnson@...<mailto:hansjohnson@...> 200 Hawkins Drive Phone: (319) 353 8587 The University of Iowa Iowa City, IA 52242 From: Peter Vanroose <peter_vanroose@...<mailto:peter_vanroose@...>> ReplyTo: Peter Vanroose <peter_y@...<mailto:peter_y@...>> Date: Thursday, November 15, 2012 10:22 AM To: "\"Matt McCormick\"" <matt.mccormick@...<mailto:matt.mccormick@...>> Cc: "\"Philip Tresadern\"" <Philip.Tresadern@...<mailto:Philip.Tresadern@...>>, Hans Johnson <hansjohnson@...<mailto:hansjohnson@...>>, Bill Lorensen <bill.lorensen@...<mailto:bill.lorensen@...>>, vxl maintainers <vxlmaintainers@...<mailto:vxlmaintainers@...>> Subject: Re: API change of vnl_math to namespace There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* #defines. Currently, these backward compatibility defines are unconditionally visible. Objections?  Peter. Matt McCormick <matt.mccormick@...<mailto:matt.mccormick@...>> wrote: A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the CMakeLists.txt: option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." OFF) mark_as_advanced(VXL_LEGACY_REMOVE) In core/vxl_config.h.in #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern <Philip.Tresadern@...<mailto:Philip.Tresadern@...>> wrote: > I can confirm that adding the following macros directly to vnl_math.h work (at least under Visual Studio 2005): > > #define vnl_math_isnan vnl_math::isnan > #define vnl_math_isinf vnl_math::isinf > #define vnl_math_isfinite vnl_math::isfinite > #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven > #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup > #define vnl_math_rnd vnl_math::rnd > #define vnl_math_floor vnl_math::floor > #define vnl_math_ceil vnl_math::ceil > #define vnl_math_abs vnl_math::abs > #define vnl_math_max vnl_math::max > #define vnl_math_min vnl_math::min > #define vnl_math_sqr vnl_math::sqr > #define vnl_math_cube vnl_math::cube > #define vnl_math_sgn vnl_math::sgn > #define vnl_math_sgn0 vnl_math::sgn0 > #define vnl_math_squared_magnitude vnl_math::squared_magnitude > #define vnl_math_cuberoot vnl_math::cuberoot > #define vnl_math_hypot vnl_math::hypot > > If the aim is to minimize disruption, this would be my recommendation; if the aim is to persuade all users to migrate to the namespace version, however, then an '#if legacy' or separate include file might give them the nudge they require. > > Phil. > >> Original Message >> From: Peter Vanroose [mailto:peter_vanroose@...<mailto:peter_vanroose@...>] >> Sent: 14 November 2012 08:27 >> To: Matt McCormick; Johnson, Hans J >> Cc: vxlusers@...<mailto:vxlusers@...>; Bill Lorensen; ITK >> Subject: Re: [Vxlusers] API change of vnl_math to namespace >> >> >> >> Matt McCormick wrote: >> > Would it be possible to get backwardscompatibility macros like >> > #define vnl_math_abs vnl_math::abs ? >> >> Yes, of course. Good idea. >> I suppose this can go in core/vnl_math.h Or would a kind of "#if legacy..." >> switch be the preferred way? Or maybe a separate include file, say >> vnl_math_oldstyle.h ? >> >>  Peter.  ________________________________ Notice: This UI Health Care email (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 25102521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ 
From: Peter Vanroose <peter_vanroose@ya...>  20121115 16:22:37

There is already a "VNL_CONFIG_LEGACY_METHODS" CMake variable; I'd propose to put "#if VNL_CONFIG_LEGACY_METHODS" around those vnl_math_* #defines. Currently, these backward compatibility defines are unconditionally visible. Objections?  Peter. Matt McCormick <matt.mccormick@...> wrote: A way to move forward could be a ITK_LEGACY_REMOVE variable defined in the CMakeLists.txt: option(VXL_LEGACY_REMOVE "Remove legacy code for backwards compatibility." OFF) mark_as_advanced(VXL_LEGACY_REMOVE) In core/vxl_config.h.in #cmakedefine VXL_LEGACY_REMOVE @VXL_LEGACY_REMOVE@ and surround the compatibility with a "#if !defined( VXL_LEGACY_REMOVE )". On Wed, Nov 14, 2012 at 2:38 PM, Philip Tresadern <Philip.Tresadern@...> wrote: > I can confirm that adding the following macros directly to vnl_math.h work (at least under Visual Studio 2005): > > #define vnl_math_isnan vnl_math::isnan > #define vnl_math_isinf vnl_math::isinf > #define vnl_math_isfinite vnl_math::isfinite > #define vnl_math_rnd_halfinttoeven vnl_math::rnd_halfinttoeven > #define vnl_math_rnd_halfintup vnl_math::rnd_halfintup > #define vnl_math_rnd vnl_math::rnd > #define vnl_math_floor vnl_math::floor > #define vnl_math_ceil vnl_math::ceil > #define vnl_math_abs vnl_math::abs > #define vnl_math_max vnl_math::max > #define vnl_math_min vnl_math::min > #define vnl_math_sqr vnl_math::sqr > #define vnl_math_cube vnl_math::cube > #define vnl_math_sgn vnl_math::sgn > #define vnl_math_sgn0 vnl_math::sgn0 > #define vnl_math_squared_magnitude vnl_math::squared_magnitude > #define vnl_math_cuberoot vnl_math::cuberoot > #define vnl_math_hypot vnl_math::hypot > > If the aim is to minimize disruption, this would be my recommendation; if the aim is to persuade all users to migrate to the namespace version, however, then an '#if legacy' or separate include file might give them the nudge they require. > > Phil. > >> Original Message >> From: Peter Vanroose [mailto:peter_vanroose@...] >> Sent: 14 November 2012 08:27 >> To: Matt McCormick; Johnson, Hans J >> Cc: vxlusers@...; Bill Lorensen; ITK >> Subject: Re: [Vxlusers] API change of vnl_math to namespace >> >> >> >> Matt McCormick wrote: >> > Would it be possible to get backwardscompatibility macros like >> > #define vnl_math_abs vnl_math::abs ? >> >> Yes, of course. Good idea. >> I suppose this can go in core/vnl_math.h Or would a kind of "#if legacy..." >> switch be the preferred way? Or maybe a separate include file, say >> vnl_math_oldstyle.h ? >> >>  Peter.  
From: Ian Scott <scottim@im...>  20121109 09:52:00

Committed a fix to the repository version of the website. I don;t knoe how to force the website itself to update though. Ian. On 09/11/2012 03:26, Todd Rovito wrote: > Greetings, > The link on the front of vxl.sourceforge.net to the IUE (Image > Understanding Environment) seems to have been hacked and is going to > an inappropriate web site. I suggest that somebody remove the link > ASAP. > > Thanks > >  > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Vxlusers mailing list > Vxlusers@... > https://lists.sourceforge.net/lists/listinfo/vxlusers > 
From: Ian Scott <scottim@im...>  20121102 11:21:00

Hi everyone, I thought I ought to tell everyone to expect significantly less contribution from me in future. Imorphics have finally got to the point of delivering software for use in regulated medical devices. Whilst learning our way around the various regulations, it has become clear that we cannot carry on using the open source releases of VXL. So a few months ago, we forked off our own private copy of the core libraries that we use, and will maintain these internally. I'd like to thank everyone for helping to provide such a useful and well written set of software. I'm grateful for everyone's help and encouragement over the years. I'll probably still watch the mailing lists, and I'm happy to answer any questions, especially regarding vil and vsl. I've kept a checkout and build of the public repository on my machine, and I'll be happy to track down any bugs I might be responsible for. Given that I don't have a stake in the future direction of VXL, I have and will refrain from getting involved in those debates. I currently have administrative privileges over the VXL project at SourceForge. I'm happy to continue with these vanishingly minor duties (adding people to the commit list), but if you want me to relinquish them  please let me know. Thanks again, Ian. 