[IPython-dev] nbconvert on Scientific Linux 5

[Jon Wilson]

So I did.  My apologies.

[1]: https://github.com/vincenthz/hs-cipher-aes/issues/25
[2]: https://github.com/jgm/pandoc/issues/1380

Regards,
Jon

On 06/29/2014 04:32 PM, Aaron S. Meurer wrote:
> You forgot to include the links.
>
> Aaron Meurer
>
>> On Jun 29, 2014, at 3:49 PM, Jon Wilson <jsw at fnal.gov> wrote:
>>
>> Total victory!  Nbconvert now works on the SUF cluster at SLAC! It's a
>> totally ad-hoc install, but I don't care.
>>
>> Ok, I explained how I solved the crypto problem, by modifying the C
>> code.  I opened an issue for that on github [1].
>>
>> The regex problem, after a brief discussion with the developers via
>> another github issue [2], was solved by installing the PCRE C library
>> from source (or from distro's package manager probably would have worked
>> as well), and then telling cabal (the Haskell installer-thing) to use a
>> different regex library than the default.
>>
>> cabal install --reinstall --force-reinstalls pandoc hightlighting-kate
>> -fpcre-light
>>
>> Maybe I'll write a blog post about my troubles.  Of course to do that
>> I'd have to start a blog...
>> Regards,
>> Jon
>>
>>
>>> On 06/29/2014 12:04 AM, Jon Wilson wrote:
>>> Hi Aaron,
>>> I solved that problem.  The issue was that cipher-aes uses the AESNI
>>> instruction set, but the CPUs in the machine I'm on predate that
>>> instruction set.  Luckily there was a C flag that I could unset in order
>>> to force the use of a software-only implementation.
>>>
>>> The question of AES crypto as a dependency of pandoc is symptomatic of
>>> what is my growing opinion of Haskell packages: insufficient
>>> modularity.  Haskell-platform won't build unmodified without OpenGL, yet
>>> there are many things one might want to do with Haskell that work fine
>>> without OpenGL.  Similarly, pandoc doesn't use crypto, but its build
>>> fails if unrelated packages won't build.  Quite frustrating.
>>>
>>> Now my problem is with the builtin regex library, which complains of
>>> undefined symbols at the linker stage.  I thought that it couldn't find
>>> the PCRE C library, but that is apparently not the case.  I found an
>>> issue on github, so we'll see if any solutions are forthcoming from the
>>> developer.
>>> Regards,
>>> Jon
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev