[Insight-users] Re: itk java wrapper on cygwin problem (Progress)
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Fri Jul 28 16:17:10 EDT 2006
Le Fri, 28 Jul 2006 22:00:04 +0200, Michael Bell <michael.bell at acm.org> a
écrit:
> Gaetan,
>
> I stepped back after Simon's email and tried to wrap the
> itkCenteredVersorTransformInitializer, which is a subclass of
> itkCenteredTransformInitializer with itkVersorRigid3DTransform<double>
> hard-coded as the templated transform. So, it only takes the two image
> parameters:
> WRAP_CLASS("itk::CenteredVersorTransformInitializer" POINTER)
> WRAP_IMAGE_FILTER("${WRAP_ITK_ALL_TYPES}" 2)
> END_WRAP_CLASS()
>
> Is it necessary to wrap the superclass first?
Yes, you must wrap the super class (not necessary first). The simplest way
to do that is to use the option POINTER_WITH_SUPERCLASS
WRAP_CLASS("itk::CenteredVersorTransformInitializer"
POINTER_WITH_SUPERCLASS)
WRAP_IMAGE_FILTER("${WRAP_ITK_ALL_TYPES}" 2)
END_WRAP_CLASS()
But with that option, the class is not clearly available for the user, so
if the super class is useful, and may be used by the user, you should not
use the POINTER_WITH_SUPERCLASS option and should wrap it by hand
>
> I got several instances of the following error with make:
> Common/itkCenteredTransformInitializer.txx:76: instantiated from
> `void itk::CenteredTransformInitializer<TTransform, TFixedImage,
> TMovingImage>::InitializeTransform() const [with TTransform =
> itk::VersorRigid3DTransform<double>, TFixedImage =
> itk::Image<std::complex<float>, 3>, TMovingImage =
> itk::Image<std::complex<float>, 3>]'
>
> Common/itkCenteredVersorTransformInitializer.txx:42: instantiated
> from `void itk::CenteredVersorTransformInitializer<TFixedImage,
> TMovingImage>::InitializeTransform() const [with TFixedImage =
> itk::Image<std::complex<float>, 3>, TMovingImage =
> itk::Image<std::complex<float>, 3>]'
>
> Modules/BaseTransforms/wrap_itkCenteredVersorTransformInitializerJava.cxx:1176:
> instantiated from here
> Algorithms/itkImageMomentsCalculator.txx:112:
> cannot convert `const std::complex<float>' to `double' in
> initialization
>
> The important part in the above mess is that the image is templated as:
> Image<std::complex<float>, 3>
> so the code "double value = it.Value();" fails.
> Why is the pixel type coming up complex?
Because you have used ${WRAP_ITK_ALL_TYPES} which obviously contains all
the types choosed by the user, including the itk::Vector<...>,
itk::CovariantVector<...>, itk::RGBPixel<..> and std::complex<...>. What
you want is surely ${WRAP_ITK_SCALAR}, or ${WRAP_ITK_REAL}.
WRAP_CLASS("itk::CenteredVersorTransformInitializer"
POINTER_WITH_SUPERCLASS)
WRAP_IMAGE_FILTER("${WRAP_ITK_SCALAR}" 2)
END_WRAP_CLASS()
Finally, I'm using
WRAP_CLASS("itk::CenteredVersorTransformInitializer"
POINTER_WITH_SUPERCLASS)
WRAP_IMAGE_FILTER_SCALAR(2)
END_WRAP_CLASS()
because it's shorter - but that's not necessary :-)
>
> thanks,
> michael
>
>
> On 7/28/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> On Fri, 28 Jul 2006 16:51:59 +0200, Michael Bell <michael.bell at acm.org>
>> wrote:
>>
>> > Gaetan,
>> >
>> > I wrapped itkVersorRigid3DTransformOptimizer. No problem, amazingly
>> easy.
>> > Now I need to wrap CenteredTransformInitializer. It has three template
>> > classes:
>> > Tansform,Image,Image. How do I do the transformType? (In this case it
>> > is VersorRigid3DTransform).
>>
>> You will have to use the "low level" macro of wrap ITK. Nothing really
>> complex though. The hard part will be to find a good name for the
>> VersorRigid3DTransform template parameter.
>>
>> Here is what I would put in the file
>> wrap_itkCenteredTransformInitializer.cmake:
>>
>> WRAP_INCLUDE("itkVersorRigid2DTransformOptimizer.h")
>> WRAP_INCLUDE("itkVersorRigid3DTransformOptimizer.h")
>>
>> FILTER_DIMS(dims "2;3")
>> WRAP_CLASS("itk::CenteredTransformInitializer" POINTER)
>> FOREACH(d ${dims})
>> FOREACH(t ${WRAP_ITK_SCALAR})
>> WRAP_TEMPLATE("aVeryGoodName${ITKM_D}${ITKM_I${t}${d}}${ITKM_I${t}${d}}"
>> "itk::VersorRigid${d}DTransformOptimizer< ${ITKT_D}
>> >,${ITKT_I${t}${d}},${ITKT_I${t}${d}}")
>> ENDFOREACH(t)
>> ENDFOREACH(d)
>> END_WRAP_CLASS()
>>
>>
>> WRAP_INCLUDE() macro is used to included the
>> VersorRigid2DTransformOptimizer and VersorRigid3DTransformOptimizer
>> headers, which are not included by default (contrary to Image header for
>> example)
>>
>> FILTER_DIMS() select the dimensions you give in parameter in the
>> dimensions choosed by the user. If the user choose the dimensions 1, 2,
>> 3
>> and 4, dims will contain 2 and 3. If he choose only dim 3 and 11, dims
>> will contain only 3. This is required because this filter seems to work
>> only for dimensions 2 and 3 (tell me if I'm wrong)
>>
>> WRAP_TEMPLATE() create a instantiation of a template. The first
>> parameter
>> is the name appended to the class name to for the instance name. The
>> second parameter is the template parameters. "aVeryGoodName" here is a
>> short name to design the VersorRigid?DTransformOptimizer - I let you
>> find
>> it, I have no imagination for the names :-). It can be several chars, by
>> convention in upper case, and have to be expressive enough to let you
>> know
>> quickly which parameter it design.
>> ${ITKM_I${t}${d}} is the name of an Image with pixel type ${t} and
>> dimension ${d} ("IF2" for pixel type float and dimension 2)
>> ${ITKT_I${t}${d}} is the Image type for pixel type ${t} and dimension
>> ${d}
>> ("itk::Image< float, 2 >" for pixel type float and dimension 2)
>>
>> The 2 FOREACH loop let us call WRAP_TEMPLATE() for all the dimensions
>> selected by the user (and filtered by us) and all the scalar type
>> selected
>> by the user. If only the floating point pixel type are useful in your
>> case, just replace WRAP_ITK_SCALAR by WRAP_ITK_REAL.
>>
>> Finally, I have considered in that example that
>> VersorRigid?DTransformOptimizer is useful only with a double as template
>> parameter (that's why I put a ${ITKM_D} in the name, and a ${ITKT_D} in
>> the template parameters), but I can be wrong, and other types may be
>> useful :-)
>>
>> I hope that's clear enough. Do not hesitate to ask if that's not the
>> case !
>>
>> Gaetan
>>
>>
>>
>>
>> >
>> > thanks,
>> > michael
>> >
>> > On 7/27/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >>
>> >> I forgot to say that darcs works with http, if you don't need to
>> have a
>> >> write access to the repository. The patches can be sent by email
>> (darcs
>> >> send), or pushed to the repository through ssh.
>> >> Most of the time, the firewalls are not a problem.
>> >>
>> >> Thanks again
>> >>
>> >> Gaetan
>> >>
>> >>
>> >>
>> >> Le Thu, 27 Jul 2006 20:29:38 +0200, Michael Bell
>> <michael.bell at acm.org>
>> >> a
>> >> écrit:
>> >>
>> >> > Gaetan,
>> >> >
>> >> > Unfortunately, I am behind a firewall, and I can not use darcs or
>> cvs.
>> >> >
>> >> > The attached patch has grammar and spelling fixes, but no content
>> >> > changes. The document is well written, and I will try to add my
>> first
>> >> > class today or tomorrow.
>> >> >
>> >> > thanks,
>> >> > michael
>> >> >
>> >> > On 7/27/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >> >> On Thu, 27 Jul 2006 17:51:28 +0200, Michael Bell
>> >> <michael.bell at acm.org>
>> >> >> wrote:
>> >> >>
>> >> >> > Gaetan,
>> >> >> >
>> >> >> > I'm reading through the pdf now, and it is very helpful. As a
>> >> native
>> >> >> > English speaker, may I be of assistance in editing some spelling
>> >> and
>> >> >> > grammar? Is the document available for changing?
>> >> >>
>> >> >> sure ! any help is welcome :-)
>> >> >> The article is available in article/Article.tex . The best way to
>> >> record
>> >> >> the changes is to use darcs (usage is partially explained in the
>> >> >> article),
>> >> >> but if don't want to use it, a simple patch would be ok :-)
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Gaetan
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > thanks,
>> >> >> > michael
>> >> >> >
>> >> >> > On 7/26/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >> >> >>
>> >> >> >> Some registration files were added some days ago by Charl P.
>> >> Botha.
>> >> >> >> It can be a good starting point. See :
>> >> >> >>
>> >> >>
>> >>
>> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkDemonsRegistrationFilter.cmake
>> >> >> >>
>> >> >>
>> >>
>> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkLevelSetMotionRegistrationFilter.cmake
>> >> >> >>
>> >> >>
>> >>
>> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkSymmetricForcesDemonsRegistrationFilter.cmake
>> >> >> >>
>> >> >> >> The WrapITK article also contains some doc - I didn't get
>> feedback
>> >> >> about
>> >> >> >> it yet, so I'm not sure it si good enough to write wrappers
>> >> without
>> >> >> >> help:
>> >> >> >>
>> >> >>
>> >>
>> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK_-_Enhanced_languages_support_for_the_Insight_Toolkit.pdf
>> >> >> >>
>> >> >> >> Gaetan
>> >> >> >>
>> >> >> >> Le Wed, 26 Jul 2006 18:29:36 +0200, Michael Bell
>> >> >> <michael.bell at acm.org>
>> >> >> >> a
>> >> >> >> écrit:
>> >> >> >>
>> >> >> >> > Gaetan,
>> >> >> >> >
>> >> >> >> > It is the registration tools that I am interested in, so this
>> >> >> should
>> >> >> >> > be perfect. I will look into things and come back with
>> >> questions.
>> >> >> >> >
>> >> >> >> > thanks,
>> >> >> >> > michael
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 7/26/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
>> wrote:
>> >> >> >> >> On Wed, 26 Jul 2006 16:18:52 +0200, Michael Bell
>> >> >> >> <michael.bell at acm.org>
>> >> >> >> >> wrote:
>> >> >> >> >>
>> >> >> >> >> > Gaetan,
>> >> >> >> >> >
>> >> >> >> >> > The only issue for me will be the classes that are not
>> >> wrapped.
>> >> >> Why
>> >> >> >> >> > are particular classes not wrapped? Can I help remedy the
>> >> >> >> situation?
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> I have tried to wrap as much classes as possible (63% of the
>> >> >> filters
>> >> >> >> are
>> >> >> >> >> wrapped at this time). However, ITK is a large toolkit, and
>> I
>> >> >> don't
>> >> >> >> >> always
>> >> >> >> >> have the needed knowledge to choose the revelant template
>> >> >> parameters.
>> >> >> >> >> That's the case for example for the registration part which
>> I
>> >> have
>> >> >> >> never
>> >> >> >> >> used (and do not plan to use).
>> >> >> >> >> So yes you can help, just by creating the new wrappers with
>> the
>> >> >> >> revelant
>> >> >> >> >> template parameters.
>> >> >> >> >> The syntax has been made to be easy to use, and I would be
>> >> >> pleased to
>> >> >> >> >> help
>> >> >> >> >> to do that.
>> >> >> >> >>
>> >> >> >> >> Let me know if you are interested in adding some new classes
>> >> >> >> >>
>> >> >> >> >> Gaetan
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> > thanks,
>> >> >> >> >> > michael
>> >> >> >> >> >
>> >> >> >> >> > On 7/26/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
>> >> wrote:
>> >> >> >> >> >> On Wed, 26 Jul 2006 15:59:55 +0200, Michael Bell
>> >> >> >> >> <michael.bell at acm.org>
>> >> >> >> >> >> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> > Gaetan,
>> >> >> >> >> >> >
>> >> >> >> >> >> > I am using ext3 on linux, which has a maximum filesize
>> of
>> >> 255
>> >> >> >> >> >> > characters. I see that Brad has addressed possible
>> >> solutions
>> >> >> to
>> >> >> >> >> this.
>> >> >> >> >> >> >
>> >> >> >> >> >> > I commented out the MetaDataDictionary, and the rest of
>> >> the
>> >> >> >> compile
>> >> >> >> >> >> > finished without errors. Things seem to run well.
>> >> >> >> >> >>
>> >> >> >> >> >> Great !
>> >> >> >> >> >> I'll try to fix that issue when I get some free time.
>> >> >> >> >> >>
>> >> >> >> >> >> > I noticed that some
>> >> >> >> >> >> > classes are named differently than the straight itk
>> >> wrapping.
>> >> >> >> For
>> >> >> >> >> >> > example: itkImageMetricIF3 instead of itkImageMetricF3.
>> >> Does
>> >> >> >> the I
>> >> >> >> >> >> > stand for Image?
>> >> >> >> >> >>
>> >> >> >> >> >> That's it
>> >> >> >> >> >> Several changes were made in the naming policy, to make
>> it
>> >> more
>> >> >> >> >> >> expressive, for example, the I for an Image, VI for a
>> >> >> VectorImage,
>> >> >> >> >> ...
>> >> >> >> >> >>
>> >> >> >> >> >> Let me know if you found other problems
>> >> >> >> >> >>
>> >> >> >> >> >> Gaetan
>> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> > Thanks for your help,
>> >> >> >> >> >> > michael
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 7/25/06, Gaëtan Lehmann
>> <gaetan.lehmann at jouy.inra.fr>
>> >> >> wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Hi,
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> I also have the same file with a very long name in my
>> >> build
>> >> >> >> tree,
>> >> >> >> >> >> but I
>> >> >> >> >> >> >> don't have any problem to access it. I thought this
>> kind
>> >> of
>> >> >> >> >> problem
>> >> >> >> >> >> was
>> >> >> >> >> >> >> limited to windows (I say that but André didn't report
>> >> any
>> >> >> >> problem
>> >> >> >> >> >> like
>> >> >> >> >> >> >> that). What is you file system ?
>> >> >> >> >> >> >> This kind of problem is already know and has been
>> fixed
>> >> for
>> >> >> >> string
>> >> >> >> >> >> lists
>> >> >> >> >> >> >> and vectors in files Module/Base/*SwigExtras*.
>> >> >> >> >> >> >> However, this workaround is inherited from the current
>> >> ITK
>> >> >> >> >> wrappers,
>> >> >> >> >> >> and
>> >> >> >> >> >> >> has not been modified in WrapITK - I'm not sure how it
>> >> can
>> >> >> be
>> >> >> >> >> used to
>> >> >> >> >> >> >> fix
>> >> >> >> >> >> >> your problem.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Brad, can you help on that point ?
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> As a quick fix, I think you should disable the class
>> >> which
>> >> >> use
>> >> >> >> >> this
>> >> >> >> >> >> >> type:
>> >> >> >> >> >> >> MetaDataDictionary.
>> >> >> >> >> >> >> To do that, just comment the line
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> WRAP_NON_TEMPLATE_CLASS("itk::MetaDataDictionary")
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> in the file Modules/Base/wrap_ITKCommonBase.cmake
>> >> >> >> >> >> >> Taht being said, I think you will have the same
>> problem
>> >> with
>> >> >> >> other
>> >> >> >> >> >> types
>> >> >> >> >> >> >> used in more useful classes :-/
>> >> >> >> >> >> >> Let me now if it still fail (or if it work !)
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Gaetan
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Le Tue, 25 Jul 2006 15:55:29 +0200, Michael Bell
>> >> >> >> >> >> <michael.bell at acm.org>
>> >> >> >> >> >> >> a
>> >> >> >> >> >> >> écrit:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> > Gaetan,
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > I am trying wrapitk on linux while waiting to
>> receive
>> >> >> >> VS2003. I
>> >> >> >> >> >> really
>> >> >> >> >> >> >> > like the setup, especially being able to choose
>> what is
>> >> >> >> wrapped.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > I am getting the following error while compiling
>> >> >> >> (ITK&CableSwig
>> >> >> >> >> >> 2.8):
>> >> >> >> >> >> >> > Generating wrap_ITKCommonBaseJava.cxx
>> >> >> >> >> >> >> > Unable to open
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> /data/WrapITK/Build_Linux/Java/InsightToolkit/SWIGTYPE_p_std___Rb_tree_iteratorTstd__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_t_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tR_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tp_t.java
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > The file name is too long. Any ideas on how to
>> correct
>> >> >> this?
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > thanks,
>> >> >> >> >> >> >> > michael
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > On 7/19/06, Gaëtan Lehmann
>> >> <gaetan.lehmann at jouy.inra.fr>
>> >> >> >> wrote:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Michael,
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> André Bongers reported to be able to build WrapITK
>> >> with
>> >> >> the
>> >> >> >> >> .NET
>> >> >> >> >> >> 2003
>> >> >> >> >> >> >> >> c++.
>> >> >> >> >> >> >> >> WrapITK surely still have some bugs on windows
>> >> plateform,
>> >> >> >> but
>> >> >> >> >> if
>> >> >> >> >> >> you
>> >> >> >> >> >> >> >> want
>> >> >> >> >> >> >> >> to try it, I will surely be more reactive that
>> >> official
>> >> >> ITK
>> >> >> >> >> >> >> developers.
>> >> >> >> >> >> >> >> WrapITK can be downloaded at
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK.tar.gz
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> or directly with darcs
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> darcs get --partial
>> >> >> >> >> >> >> >>
>> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> and requires ITK 2.8.1
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Gaetan
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Le Wed, 19 Jul 2006 22:10:55 +0200, Michael Bell
>> >> >> >> >> >> >> <michael.bell at acm.org>
>> >> >> >> >> >> >> >> a
>> >> >> >> >> >> >> >> écrit:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> > SwigInc.txt is being generated from
>> SwigInc.txt.in,
>> >> >> which
>> >> >> >> has
>> >> >> >> >> >> the
>> >> >> >> >> >> >> >> > extra carriage return character. I suspect this
>> is a
>> >> >> >> problem
>> >> >> >> >> >> >> because I
>> >> >> >> >> >> >> >> > am using the cygwin recommended unix files, but
>> this
>> >> >> file
>> >> >> >> is
>> >> >> >> >> a
>> >> >> >> >> >> dos
>> >> >> >> >> >> >> >> > file. If I dos2unix SwigInc.txt.in and make, this
>> >> error
>> >> >> >> goes
>> >> >> >> >> >> away,
>> >> >> >> >> >> >> and
>> >> >> >> >> >> >> >> > all of the SwigIn.txt files are correct. If I run
>> >> >> >> dos2unix on
>> >> >> >> >> >> the
>> >> >> >> >> >> >> >> > entire Wrapping directory, many problems are
>> fixed.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > Which shows the next issue:
>> >> >> >> >> >> >> >> > javac does not understand cygwin paths. This
>> issue
>> >> can
>> >> >> be
>> >> >> >> >> fixed
>> >> >> >> >> >> >> using
>> >> >> >> >> >> >> >> > cygpath.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > Which shows the next problem:
>> >> >> >> >> >> >> >> > javac VXLNumericsJava.java
>> >> >> >> >> >> >> >> > cannot resolve symbol itkbase
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > I haven't solved that problem, but I am certain
>> it
>> >> >> would
>> >> >> >> >> reveal
>> >> >> >> >> >> >> more.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > It's pretty clear that no one is maintaining the
>> >> >> wrappers
>> >> >> >> >> with
>> >> >> >> >> >> >> cygwin.
>> >> >> >> >> >> >> >> > Please make this clear somewhere in the
>> >> documentation
>> >> >> so
>> >> >> >> the
>> >> >> >> >> >> next
>> >> >> >> >> >> >> >> > person does not waste weeks on this, as I have.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > So, we know that VS8 does not work. Cygwin does
>> not
>> >> >> work.
>> >> >> >> >> What
>> >> >> >> >> >> does
>> >> >> >> >> >> >> >> > work on Windows? I can change compilers, but I
>> can't
>> >> >> spend
>> >> >> >> >> time
>> >> >> >> >> >> >> >> > hunting for a platform that does work. Please
>> >> advise.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > thanks,
>> >> >> >> >> >> >> >> > michael
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > On 7/17/06, Michael Bell <michael.bell at acm.org>
>> >> wrote:
>> >> >> >> >> >> >> >> >> ITK people,
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> I have made some progress tracking down this
>> error:
>> >> >> >> >> >> >> >> >> wrap_vnl_matrix.xml from gccxml_cc1plus:
>> >> >> >> >> >> >> >> >> error: too many filenames given. Type
>> >> gccxml_cc1plus
>> >> >> >> >> --help
>> >> >> >> >> >> for
>> >> >> >> >> >> >> >> usage
>> >> >> >> >> >> >> >> >> make[2]: ***
>> >> >> >> >> [Wrapping/CSwig/VXLNumerics/wrap_vnl_matrix.xml]
>> >> >> >> >> >> >> Error 1
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> This is the operation that fails (paths
>> shortened
>> >> for
>> >> >> >> >> >> >> readability):
>> >> >> >> >> >> >> >> >> gccxml -fxml-start=_cable_
>> >> -fxml=wrap_vnl_matrix.xml
>> >> >> >> >> >> >> >> >> --gccxml-gcc-options SwigInc.txt -DCSWIG
>> >> >> >> >> -DCABLE_CONFIGURATION
>> >> >> >> >> >> >> >> >> wrap_vnl_matrix.cxx
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> SwigInc.txt contains a list of include paths:
>> >> >> >> >> >> >> >> >>
>> >> >> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Build_Cygwin
>> >> >> >> >> >> >> >> >>
>> >> >> >> >>
>> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/Algorithms
>> >> >> >> >> >> >> >> >> ...
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/BasicFilters
>> >> >> >> >> >> >> >> >> ^M
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> Then, it has the ^M character at the end. If I
>> >> remove
>> >> >> >> this
>> >> >> >> >> >> >> character,
>> >> >> >> >> >> >> >> >> the xml file appears to be created correctly.
>> Does
>> >> >> anyone
>> >> >> >> >> know
>> >> >> >> >> >> >> where
>> >> >> >> >> >> >> >> >> this is being created, or why, or how I can
>> prevent
>> >> >> it?
>> >> >> >> Is
>> >> >> >> >> >> this an
>> >> >> >> >> >> >> >> ITK
>> >> >> >> >> >> >> >> >> problem, or a CableSwig problem?
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> Please, I'm obviously willing to do the leg
>> work,
>> >> but
>> >> >> it
>> >> >> >> >> will
>> >> >> >> >> >> >> take me
>> >> >> >> >> >> >> >> >> 10 times as long to figure this out than if an
>> ITK
>> >> >> >> developer
>> >> >> >> >> >> would
>> >> >> >> >> >> >> >> >> step up and help. I've already shown that I was
>> not
>> >> >> the
>> >> >> >> >> first
>> >> >> >> >> >> >> person
>> >> >> >> >> >> >> >> >> to deal with this problem, and there are likely
>> >> others
>> >> >> >> who
>> >> >> >> >> have
>> >> >> >> >> >> >> not
>> >> >> >> >> >> >> >> >> said anything.
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> thanks,
>> >> >> >> >> >> >> >> >> michael
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> >> michael.bell at acm.org
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> Utilisant le client e-mail révolutionnaire d'Opera
>> :
>> >> >> >> >> >> >> >> http://www.opera.com/mail/
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> Utilisant le client e-mail révolutionnaire d'Opera :
>> >> >> >> >> >> >> http://www.opera.com/mail/
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> Gaëtan Lehmann
>> >> >> >> >> >> Biologie du Développement et de la Reproduction
>> >> >> >> >> >> INRA de Jouy-en-Josas (France)
>> >> >> >> >> >> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>> >> >> >> >> >> http://voxel.jouy.inra.fr
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Gaëtan Lehmann
>> >> >> >> >> Biologie du Développement et de la Reproduction
>> >> >> >> >> INRA de Jouy-en-Josas (France)
>> >> >> >> >> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>> >> >> >> >> http://voxel.jouy.inra.fr
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Utilisant le client e-mail révolutionnaire d'Opera :
>> >> >> >> http://www.opera.com/mail/
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Gaëtan Lehmann
>> >> >> Biologie du Développement et de la Reproduction
>> >> >> INRA de Jouy-en-Josas (France)
>> >> >> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>> >> >> http://voxel.jouy.inra.fr
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Utilisant le client e-mail révolutionnaire d'Opera :
>> >> http://www.opera.com/mail/
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Gaëtan Lehmann
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>> http://voxel.jouy.inra.fr
>>
>
>
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr
More information about the Insight-users
mailing list