Gabor,

thanks for your complete answer. I will do the changes to remove 
dependence on fabio and we can treat crashes from then on as bugs which 
need fixing.

Concerning jep  - the answer is NO. Workflows do not depend on jep. A 
separate python interpreter is started for running the python code. This 
avoids dependencies issues.

However jep is heavily used in the fable 3dxrd program. It is much more 
work to remove jep there. For the moment we get around the jep issues in 
fable 3dxrd by supporting only certain versions of python with fable 
e.g. only 2.6 on windows.

Personally I like(d) jep. It is fast and compact. Its a pity it doesn't 
work on all platforms for all versions of python and all compilers. The 
pain of getting it to work for various versions of python and c 
compilers requires a lot of effort. I dream of working on systems one 
day which support cross language calling seamlessly (Java calling Python 
calling C++ and vice versa). I think .NET tried to do this but then it 
only worked on one platform and it does not support Java. Does it 
support Python? I reserve this discussion for a night in the pub.

Andy

On 05/25/2012 10:32 AM, Gábor Náray wrote:
> Hi Andy,
>
> Short answer: you can remove fabio.
>
> Long answer: At the beginning I was told that the DLS' cbfloader 
> crashes on older linuxes, thus I started to write my own cbfloader. 
> Since I worked on fable imageviewer, and Fabio contained a loader, I 
> decided to add my loader to Fabio. Although Fabio can load cbf files 
> with jep, I was curious how faster another loader can be using C++. At 
> the end, my cbfloader got ready within Fabio, replacing the JEP 
> cbfloader, however currently supporting only linux (in contrast of 
> DLS' cbfloader, which supports win32 too). If we drop Fabio, then we 
> will have to use DLS' cbfloader, which is fine if it does not crash. 
> To see if it crashes, I have to find a linux where it indeed crashes, 
> and then I can find a solution to avoid the crash. Another alternative 
> is that we can consider DLS' cbfloader working 100%, and when it 
> crashes somewhere, a bug report will be added and then I will be able 
> to try to fix it. Another thing I will need to check what values the 
> DLS' cbfloader gives from the header of different types of cbf file, 
> but that has less priority at the moment.
>
> By the way, is not python (and thus Jep) used in the workflows?
>
> Regards,
> Gábor
>
> On 2012-05-25 06:49, Andy Gotz wrote:
>> Hi Gabor,
>>
>> I am trying to address the fabio issue (under GPL licence) before the
>> dawn release.
>>
>> Do I understand correctly from this email that you do not need fabio 
>> anymore?
>>
>> Much as I like fabio even if we changed the license I agree there is
>> an issue making jep run on all platforms (especially Windows). If you
>> do not need fabio anymore I will remove it before the release. The
>> main immediate loss will be support for some useful file formats like
>> the GE and Oxford diffraction detectors and probably others too. But
>> we will have to reimplement in the dawn file loader.
>>
>> Andy
>>
>> On 05/16/2012 03:18 PM, Gábor Náray wrote:
>>> Hi Peter,
>>>
>>> Thank you for the information. Now I managed to compile CBFlib and 
>>> produce the jar and so files on linux. So at the moment we compile 
>>> stuff on operating systems we use, and add the compiled files 
>>> (libraries) to DAWN, thus regarding CBFloader the Win32, Linux32 and 
>>> Linux64 are supported? From this aspect my simplified CBFloader is 
>>> not too bad, it supports Linux32 and Linux64 (currently). :-) Anyway 
>>> I still do not know how we could store C++ stuff in DAWN, so users 
>>> could compile the files if they wish, but would not disturb those 
>>> without CDT.
>>>
>>> Cheers,
>>> Gábor
>>>
>>> On 16/05/2012 14:49, [log in to unmask] wrote:
>>>> Hi Gabor,
>>>>
>>>> I contribute a SWIG binding to CBFlib. You should be able to 
>>>> download their source code and compile it on the OS and 
>>>> architecture you require. That regex library is required for our 
>>>> MinGW 32-bit build - you may need a similar thing for a 64-bit build.
>>>>
>>>> Peter
>>>>
>>>>> -----Original Message-----
>>>>> From: Gerring, Matt (DLSLtd,RAL,DIA)
>>>>> Sent: 16 May 2012 13:42
>>>>> To: [log in to unmask]; Chang, Peter (DLSLtd,RAL,DIA)
>>>>> Subject: RE: [DAWN] CBFLoader questions
>>>>>
>>>>> Hello Gabbor,
>>>>>
>>>>> One of our developers, Peter Chang, contributed jni bindings back
>>>>> to the CBF project. There is a makefile for the JNI as part of that
>>>>> project when you download the source. I recommend talking to Peter
>>>>> further ;)
>>>>>
>>>>> Matt
>>>>>
>>>>> -----Original Message-----
>>>>> From: Main mail list for the dawn collaboration
>>>>> [mailto:[log in to unmask]] On Behalf Of Gábor Náray
>>>>> Sent: 16 May 2012 12:41
>>>>> To: [log in to unmask]
>>>>> Subject: [DAWN] CBFLoader questions
>>>>>
>>>>> Hello,
>>>>>
>>>>> I am curious what operating systems the Diamond's CBFLoader
>>>>> supports.
>>>>> Considering the MANIFEST.MF of
>>>>> uk.ac.diamond.CBFlib_1.0.0.201112071158.jar, it supports Win32,
>>>>> Linux32 and Linux64, right? How does it support Macintosh then? And
>>>>> what about Win64? Is there an up-to-date document somewhere
>>>>> describing the requirements of DAWN and what it supports?
>>>>>
>>>>> Obviously the best would be if the authors of CBFlib would support
>>>>> Java, but I have not found any Java source code. By the way,
>>>>> somehow the libcbf_wrap.so in the mentioned jar file was compiled
>>>>> from source, is that source available? And what can be that
>>>>> libgnurx-0.dll required by
>>>>> Win32 platform?
>>>>>
>>>>> Part of MANIFEST.MF:
>>>>> Bundle-NativeCode: lib/win32-x86/cbf_wrap.dll ; lib/win32-
>>>>> x86/libgnurx
>>>>>    -0.dll ;osname=Win32; processor=x86; processor=x86-64,lib/linux-
>>>>> x86/l
>>>>>    ibcbf_wrap.so;osname=Linux; processor=x86,lib/linux-
>>>>> x86_64/libcbf_wra
>>>>>    p.so;osname=Linux; processor=x86-64
>>>>>
>>>>> Cheers,
>>>>> Gábor
>>>
>>>