Re: octave license is incompatible with openssl

[Alex Vong]

Kei Kebreau <address@hidden> writes:

> Alex Vong <address@hidden> writes:
>
>> Mike Miller <address@hidden> writes:
>>
>>> On Wed, Aug 10, 2016 at 14:43:57 +0800, Alex Vong wrote:
>>>> I thought it was an optional dependency because when I run
>>>> `./configure --help', it contains the following help:
>>>> 
>>>>   --with-openssl          use libcrypto hash routines. Valid ARGs are: 
>>>> 'yes',
>>>>                           'no', 'auto' => use if available, 'optional' => 
>>>> use
>>>>                           if available and warn if not available; default 
>>>> is
>>>>                           'no'
>>>> 
>>>> 
>>>> Perhaps someone unaware of the issue adds this? Should I open a bug
>>>> report on this?
>>>
>>> Thanks for pointing that out. I wasn't aware of this until now. This
>>> configure option actually comes directly from the gnulib project. You'll
>>> notice that the default is "no", which is exactly as it should be.
>>>
>>> Octave provides some standard hash functions that are built on GPL
>>> compatible functions provided by gnulib. As a side effect of enabling
>>> these gnulib modules, gnulib automatically adds the `--with-openssl`
>>> option to allow the user to specify that the OpenSSL libcrypto functions
>>> should be used instead.
>>>
>>> I couldn't find this described or documented anywhere, just had to go
>>> digging through the configuration macros, e.g.
>>>
>>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/gl-openssl.m4
>>> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/sha1.m4
>>>
>>> Cheers,
>>
>> I see. Thanks for the explaination. As Mark has pointed out, the problem
>> seems to be in the curl package.
>>
>> Finally, some unrelated stuff, I hope octave would have a byte code
>> interpreter soon. I would suggest to write it in rpython, it seems to be
>> the easiest way to have jit these days.
>>
>> Cheers,
>> Alex
>
> IIRC, Octave has experimental JIT support using LLVM.

Yes, I am aware that octave has an experimental llvm jit, but I heard
that llvm is a quick moving target and the api is not as stable as you
would like. Much energy needed to be devoted to simply keep in sync with
upstream.

Also, writing in restricted python seems more pleasant than c++. The jit
is auto-generated in the sense that you only need to mark when the loop
starts and when the loop stops. Finally, there is even a paper
(understandable to hobbyists) on implementing racket using
rpython[0]. These all looks promising to me.

The really downside is that the translation time is super long (time
takes to build the interpreter), because expensive static analysis needs
to be performed to remove malloc, assertions, inline function
calls... to make the interpreter itself fast enough (not the code it
generates I guess).

[0]: http://homes.soic.indiana.edu/samth/pycket-draft.pdf