[Insight-users] Re: itk java wrapper on cygwin problem (Progress)
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Fri Jul 28 11:27:15 EDT 2006
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
More information about the Insight-users
mailing list