unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* octave license is incompatible with openssl
@ 2016-08-04 16:35 Alex Vong
  2016-08-04 17:10 ` John Darrington
  2016-08-05  6:50 ` Ricardo Wurmus
  0 siblings, 2 replies; 31+ messages in thread
From: Alex Vong @ 2016-08-04 16:35 UTC (permalink / raw)
  To: guix-devel

Hi guixes,

First, congratulations to Ricardo Wurmus as new maintainer and the new
0.11 release is good (it passed all tests)!

I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
far as I know, gplv3 is incompatible with openssl license
(https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

How should we fix this?


Cheers,
Alex

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-04 16:35 octave license is incompatible with openssl Alex Vong
@ 2016-08-04 17:10 ` John Darrington
  2016-08-04 17:20   ` ng0
  2016-08-05  9:03   ` Alex Vong
  2016-08-05  6:50 ` Ricardo Wurmus
  1 sibling, 2 replies; 31+ messages in thread
From: John Darrington @ 2016-08-04 17:10 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

I would not be at all suprised if there were more incompatibilities like
this.  Ought we not have  a lint rule that checks this?

J'

On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
     Hi guixes,
     
     First, congratulations to Ricardo Wurmus as new maintainer and the new
     0.11 release is good (it passed all tests)!
     
     I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
     far as I know, gplv3 is incompatible with openssl license
     (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
     
     How should we fix this?
     
     
     Cheers,
     Alex

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-04 17:10 ` John Darrington
@ 2016-08-04 17:20   ` ng0
  2016-08-05  9:08     ` Alex Vong
  2016-08-05  9:03   ` Alex Vong
  1 sibling, 1 reply; 31+ messages in thread
From: ng0 @ 2016-08-04 17:20 UTC (permalink / raw)
  To: John Darrington, Alex Vong; +Cc: guix-devel

John Darrington <john@darrington.wattle.id.au> writes:

> I would not be at all suprised if there were more incompatibilities like
> this.  Ought we not have  a lint rule that checks this?
>
> J'
>
> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>      Hi guixes,
>      
>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>      0.11 release is good (it passed all tests)!
>      
>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>      far as I know, gplv3 is incompatible with openssl license
>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>      
>      How should we fix this?
>      
>      
>      Cheers,
>      Alex
>
> -- 
> Avoid eavesdropping.  Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>

Isn't this an upstream problem? I don't know octave but is openssl
required? Can it be replaced by something different?

Does this require upstream action/reporting?
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-04 16:35 octave license is incompatible with openssl Alex Vong
  2016-08-04 17:10 ` John Darrington
@ 2016-08-05  6:50 ` Ricardo Wurmus
  2016-08-06  1:52   ` Alex Vong
  1 sibling, 1 reply; 31+ messages in thread
From: Ricardo Wurmus @ 2016-08-05  6:50 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel


Alex Vong <alexvong1995@gmail.com> writes:

> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
> far as I know, gplv3 is incompatible with openssl license
> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

Looks like you’re right.  Other projects add a special openSSL linking
exception, but Octave does not seem to account for this.

> How should we fix this?

It seems that the use of openssl in Octave is optional, so we could
probably just remove it.  From a cursory look it appears that it is used
for not much more than the MD5 algorithm.  Would you like to submit a
patch that removes openssl from the inputs?

It would be good to ask the Octave project if it would be possible to
replace OpenSSL with, say, GnuTLS.

~~ Ricardo

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-04 17:10 ` John Darrington
  2016-08-04 17:20   ` ng0
@ 2016-08-05  9:03   ` Alex Vong
  2016-08-05 11:43     ` Mathieu Lirzin
  1 sibling, 1 reply; 31+ messages in thread
From: Alex Vong @ 2016-08-05  9:03 UTC (permalink / raw)
  To: John Darrington; +Cc: guix-devel

John Darrington <john@darrington.wattle.id.au> writes:

> I would not be at all suprised if there were more incompatibilities like
> this.  Ought we not have  a lint rule that checks this?
>
Indeed, in the short term, we could lint for special case, such that
openssl appears as an input for an GPLv[123](+) package.


In the long term, we could have the following in guix. Since licenses
are scheme values. I was thinking we can have procedure like:

  (compatible? l1 l2)

which is a reflexive and symmetric relation. Also, we might be able to
build compound licenses by:

  (dual-license lics ...)

and

  (intersect-license lics ...)

The 3 procedures should satisfy the following "laws":

  (compatible? l1 (dual-license lics ...))

if and only if

  (any (cut compatible? l1  <>) lics)

Similarly,

  (compatible? l1 (intersect-license lics ...))

if and only if

  (every (cut compatible? l1  <>) lics)


How do everyone think?

Cheers,
Alex

> J'
>
> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>      Hi guixes,
>      
>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>      0.11 release is good (it passed all tests)!
>      
>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>      far as I know, gplv3 is incompatible with openssl license
>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>      
>      How should we fix this?
>      
>      
>      Cheers,
>      Alex

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-04 17:20   ` ng0
@ 2016-08-05  9:08     ` Alex Vong
  0 siblings, 0 replies; 31+ messages in thread
From: Alex Vong @ 2016-08-05  9:08 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

> John Darrington <john@darrington.wattle.id.au> writes:
>
>> I would not be at all suprised if there were more incompatibilities like
>> this.  Ought we not have  a lint rule that checks this?
>>
>> J'
>>
>> On Fri, Aug 05, 2016 at 12:35:54AM +0800, Alex Vong wrote:
>>      Hi guixes,
>>      
>>      First, congratulations to Ricardo Wurmus as new maintainer and the new
>>      0.11 release is good (it passed all tests)!
>>      
>>      I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>>      far as I know, gplv3 is incompatible with openssl license
>>      (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>>      
>>      How should we fix this?
>>      
>>      
>>      Cheers,
>>      Alex
>>
>> -- 
>> Avoid eavesdropping.  Send strong encryted email.
>> PGP Public key ID: 1024D/2DE827B3 
>> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
>> See http://sks-keyservers.net or any PGP keyserver for public key.
>>
>
> Isn't this an upstream problem? I don't know octave but is openssl
> required? Can it be replaced by something different?
>
> Does this require upstream action/reporting?

I remember reading that octave devs are aware of the problem, but it is
difficult to change the license since octave has no copyright assignment
(like guix), Note that this is from my memory, so I could have got it
wrong.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-05  9:03   ` Alex Vong
@ 2016-08-05 11:43     ` Mathieu Lirzin
  0 siblings, 0 replies; 31+ messages in thread
From: Mathieu Lirzin @ 2016-08-05 11:43 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel

Alex Vong <alexvong1995@gmail.com> writes:

> John Darrington <john@darrington.wattle.id.au> writes:
>
>> I would not be at all suprised if there were more incompatibilities like
>> this.  Ought we not have  a lint rule that checks this?
>>
> Indeed, in the short term, we could lint for special case, such that
> openssl appears as an input for an GPLv[123](+) package.
>
>
> In the long term, we could have the following in guix. Since licenses
> are scheme values. I was thinking we can have procedure like:
>
>   (compatible? l1 l2)
>
> which is a reflexive and symmetric relation. Also, we might be able to
> build compound licenses by:
>
>   (dual-license lics ...)
>
> and
>
>   (intersect-license lics ...)
>
> The 3 procedures should satisfy the following "laws":
>
>   (compatible? l1 (dual-license lics ...))
>
> if and only if
>
>   (any (cut compatible? l1  <>) lics)
>
> Similarly,
>
>   (compatible? l1 (intersect-license lics ...))
>
> if and only if
>
>   (every (cut compatible? l1  <>) lics)
>
>
> How do everyone think?
>

I like the idea!

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-05  6:50 ` Ricardo Wurmus
@ 2016-08-06  1:52   ` Alex Vong
  2016-08-08 20:00     ` Leo Famulari
  0 siblings, 1 reply; 31+ messages in thread
From: Alex Vong @ 2016-08-06  1:52 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>> far as I know, gplv3 is incompatible with openssl license
>> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>
> Looks like you’re right.  Other projects add a special openSSL linking
> exception, but Octave does not seem to account for this.
>
>> How should we fix this?
>
> It seems that the use of openssl in Octave is optional, so we could
> probably just remove it.  From a cursory look it appears that it is used
> for not much more than the MD5 algorithm.  Would you like to submit a
> patch that removes openssl from the inputs?
>
Here it is. It takes a long time to track down that curl is pulling the
openssl depedency. I also upgrade octave to 4.0.3 and change to use
'tar.xz'.

> It would be good to ask the Octave project if it would be possible to
> replace OpenSSL with, say, GnuTLS.
>
I agree, should we CC/forward this discussion to octave-devel list?

> ~~ Ricardo

Cheers,
Alex


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-octave-Update-to-4.0.3.patch --]
[-- Type: text/x-diff, Size: 1923 bytes --]

From f813b22539c6cefd49471f7df3adc4b02ebcd76c Mon Sep 17 00:00:00 2001
From: Alex Vong <alexvong1995@gmail.com>
Date: Sat, 6 Aug 2016 08:52:34 +0800
Subject: [PATCH] gnu: octave: Update to 4.0.3.

  * gnu/packages/maths.scm (octave): Update to 4.0.3.
  [source]: Change to '.tar.xz'.
  [inputs]: Remove dependencies on openssl and curl.
---
 gnu/packages/maths.scm | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index fcea0bc..149c533 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -692,16 +692,19 @@ can solve two kinds of problems:
 (define-public octave
   (package
     (name "octave")
-    (version "4.0.2")
+    (version "4.0.3")
     (source
      (origin
       (method url-fetch)
       (uri (string-append "mirror://gnu/octave/octave-"
-                          version ".tar.gz"))
+                          version ".tar.xz"))
       (sha256
        (base32
-        "1hdxap3j88rpqjimnfhinym6z73wdi5dfa6fv85c13r1dk9qzk9r"))))
+        "11day29k4yfvxh4101x5yf26ld992x5n6qvmhjjk6mzsd26fqayw"))))
     (build-system gnu-build-system)
+    ;; Ideally, curl should be in the list of inputs to enable ftp support.
+    ;; It isn't because it causes octave to link against openssl which isn't allowed
+    ;; as octave's license has no openssl exception at the moment.
     (inputs
      `(("lapack" ,lapack)
        ("readline" ,readline)
@@ -709,7 +712,6 @@ can solve two kinds of problems:
        ("fftw" ,fftw)
        ("fftwf" ,fftwf)
        ("arpack" ,arpack-ng)
-       ("curl" ,curl)
        ("pcre" ,pcre)
        ("cyrus-sasl" ,cyrus-sasl)
        ("fltk" ,fltk)
@@ -719,7 +721,6 @@ can solve two kinds of problems:
        ("libxft" ,libxft)
        ("mesa" ,mesa)
        ("glu" ,glu)
-       ("openssl" ,openssl)
        ("zlib" ,zlib)))
     (native-inputs
      `(("gfortran" ,gfortran)
-- 
2.9.2


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-06  1:52   ` Alex Vong
@ 2016-08-08 20:00     ` Leo Famulari
  2016-08-09 16:00       ` Alex Vong
  0 siblings, 1 reply; 31+ messages in thread
From: Leo Famulari @ 2016-08-08 20:00 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel

On Sat, Aug 06, 2016 at 09:52:39AM +0800, Alex Vong wrote:
> Ricardo Wurmus <rekado@elephly.net> writes:
> 
> > Alex Vong <alexvong1995@gmail.com> writes:
> >
> >> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
> >> far as I know, gplv3 is incompatible with openssl license
> >> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
> >
> > Looks like you’re right.  Other projects add a special openSSL linking
> > exception, but Octave does not seem to account for this.
> >
> >> How should we fix this?
> >
> > It seems that the use of openssl in Octave is optional, so we could
> > probably just remove it.  From a cursory look it appears that it is used
> > for not much more than the MD5 algorithm.  Would you like to submit a
> > patch that removes openssl from the inputs?
> >
> Here it is. It takes a long time to track down that curl is pulling the
> openssl depedency. I also upgrade octave to 4.0.3 and change to use
> 'tar.xz'.
> 
> > It would be good to ask the Octave project if it would be possible to
> > replace OpenSSL with, say, GnuTLS.
> >
> I agree, should we CC/forward this discussion to octave-devel list?

Yes, I think we should work with them to resolve this issue.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-08 20:00     ` Leo Famulari
@ 2016-08-09 16:00       ` Alex Vong
  2016-08-09 17:27         ` Mike Miller
  0 siblings, 1 reply; 31+ messages in thread
From: Alex Vong @ 2016-08-09 16:00 UTC (permalink / raw)
  To: help-octave; +Cc: Ricardo Wurmus, guix-devel, Leo Famulari

Hi octave devs,

During a look of the octave package in guix (a functional package
manager, part of gnu), we notice octave have an optional dependency on
openssl.

However, since the license of octave (gpl3+) is incompatible
with that of openssl
(https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
resulting binary after linking is not re-distributable.

So, we drop the optional dependency to avoid the problem.

Is there any plan to fix this problem? There are some solutions we think
of: 1. add openssl linking exception to the license 2. provide support
for linking with gnutls as an alternative. In any case, I think we
should warn the user about it.

What are your ideas? (the messages below include the whole discussion on
the guix-devel mailing list)

Thanks,
Alex

Leo Famulari <leo@famulari.name> writes:

> On Sat, Aug 06, 2016 at 09:52:39AM +0800, Alex Vong wrote:
>> Ricardo Wurmus <rekado@elephly.net> writes:
>> 
>> > Alex Vong <alexvong1995@gmail.com> writes:
>> >
>> >> I notice 'octave 4.0.2' has 'openssl@1.0.2h' as one of its inputs. As
>> >> far as I know, gplv3 is incompatible with openssl license
>> >> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html).
>> >
>> > Looks like you’re right.  Other projects add a special openSSL linking
>> > exception, but Octave does not seem to account for this.
>> >
>> >> How should we fix this?
>> >
>> > It seems that the use of openssl in Octave is optional, so we could
>> > probably just remove it.  From a cursory look it appears that it is used
>> > for not much more than the MD5 algorithm.  Would you like to submit a
>> > patch that removes openssl from the inputs?
>> >
>> Here it is. It takes a long time to track down that curl is pulling the
>> openssl depedency. I also upgrade octave to 4.0.3 and change to use
>> 'tar.xz'.
>> 
>> > It would be good to ask the Octave project if it would be possible to
>> > replace OpenSSL with, say, GnuTLS.
>> >
>> I agree, should we CC/forward this discussion to octave-devel list?
>
> Yes, I think we should work with them to resolve this issue.

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 16:00       ` Alex Vong
@ 2016-08-09 17:27         ` Mike Miller
  2016-08-09 18:30           ` Ricardo Wurmus
                             ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Mike Miller @ 2016-08-09 17:27 UTC (permalink / raw)
  To: Alex Vong; +Cc: Ricardo Wurmus, guix-devel, help-octave, Leo Famulari

On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
> Hi octave devs,
> 
> During a look of the octave package in guix (a functional package
> manager, part of gnu), we notice octave have an optional dependency on
> openssl.
> 
> However, since the license of octave (gpl3+) is incompatible
> with that of openssl
> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
> resulting binary after linking is not re-distributable.

Agreed.

> So, we drop the optional dependency to avoid the problem.

Precisely what is the optional dependency that is dropped?

Octave does not directly link with OpenSSL nor use any OpenSSL
functions. The Octave package on Debian builds with all optional
dependencies enabled, and the resulting binary is linked with GnuTLS.

> Is there any plan to fix this problem? There are some solutions we think
> of: 1. add openssl linking exception to the license 2. provide support
> for linking with gnutls as an alternative. In any case, I think we
> should warn the user about it.
> 
> What are your ideas? (the messages below include the whole discussion on
> the guix-devel mailing list)

The Octave Guix package may be indirectly linking with OpenSSL through a
direct dependency such as libcurl. I would recommend that you use a
libcurl that is built against GnuTLS as we do on Debian.

AFAICS, nothing needs to be fixed in Octave.

HTH,

-- 
mike

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 17:27         ` Mike Miller
@ 2016-08-09 18:30           ` Ricardo Wurmus
  2016-08-09 21:33             ` kei
  2016-08-10  4:23           ` Mark H Weaver
  2016-08-10  6:43           ` Alex Vong
  2 siblings, 1 reply; 31+ messages in thread
From: Ricardo Wurmus @ 2016-08-09 18:30 UTC (permalink / raw)
  To: Mike Miller; +Cc: guix-devel, help-octave


Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>> So, we drop the optional dependency to avoid the problem.
>
> Precisely what is the optional dependency that is dropped?
>
> Octave does not directly link with OpenSSL nor use any OpenSSL
> functions. The Octave package on Debian builds with all optional
> dependencies enabled, and the resulting binary is linked with GnuTLS.

The “openssl” package (along with “cyrus-sasl”) was added as a new input
to our “octave” package in commit
b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
4.0.0 to 4.0.2.

I don’t know why this was done.  Maybe Kei could shed some light on
this.

~~ Ricardo

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 18:30           ` Ricardo Wurmus
@ 2016-08-09 21:33             ` kei
  2016-08-10  4:28               ` Mark H Weaver
  0 siblings, 1 reply; 31+ messages in thread
From: kei @ 2016-08-09 21:33 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, help-octave, Mike Miller

On 2016-08-09 14:30, Ricardo Wurmus wrote:
> Mike Miller <mtmiller@octave.org> writes:
> 
>> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>>> So, we drop the optional dependency to avoid the problem.
>> 
>> Precisely what is the optional dependency that is dropped?
>> 
>> Octave does not directly link with OpenSSL nor use any OpenSSL
>> functions. The Octave package on Debian builds with all optional
>> dependencies enabled, and the resulting binary is linked with GnuTLS.
> 
> The “openssl” package (along with “cyrus-sasl”) was added as a new 
> input
> to our “octave” package in commit
> b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
> 4.0.0 to 4.0.2.
> 
> I don’t know why this was done.  Maybe Kei could shed some light on
> this.
> 
> ~~ Ricardo

When I tried to build Octave 4.0.2, the build complained about missing 
SSL
and SASL libraries. Adding gnutls as a dependency (Debian users are 
advised
to use libcurl4-gnutls-dev) did not fix the issue, so I added OpenSSL to
stop the issue. It seems to me that Octave 4.0.2 (and 4.0.3, the most 
recent
version) depends on SSL for curl usage, as curl allows Octave users to 
issue
a "pkg install -forge [package_name]" command to install packages from 
the
Octave Forge repo. I didn't know that the licenses were incompatible, so 
now
we have to name (or correctly package) the Guix equivalent of 
libcurl4-gnutls-dev.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 17:27         ` Mike Miller
  2016-08-09 18:30           ` Ricardo Wurmus
@ 2016-08-10  4:23           ` Mark H Weaver
  2016-08-10  6:43           ` Alex Vong
  2 siblings, 0 replies; 31+ messages in thread
From: Mark H Weaver @ 2016-08-10  4:23 UTC (permalink / raw)
  To: Mike Miller; +Cc: guix-devel, help-octave

Mike Miller <mtmiller@octave.org> writes:
> I would recommend that you use a libcurl that is built against GnuTLS
> as we do on Debian.

Our libcurl is already built against GnuTLS.

     Mark

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 21:33             ` kei
@ 2016-08-10  4:28               ` Mark H Weaver
  2016-08-11  5:56                 ` Mike Miller
  0 siblings, 1 reply; 31+ messages in thread
From: Mark H Weaver @ 2016-08-10  4:28 UTC (permalink / raw)
  To: kei; +Cc: guix-devel, help-octave, Mike Miller

kei@openmailbox.org writes:

> On 2016-08-09 14:30, Ricardo Wurmus wrote:
>> Mike Miller <mtmiller@octave.org> writes:
>>
>>> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>>>> So, we drop the optional dependency to avoid the problem.
>>>
>>> Precisely what is the optional dependency that is dropped?
>>>
>>> Octave does not directly link with OpenSSL nor use any OpenSSL
>>> functions. The Octave package on Debian builds with all optional
>>> dependencies enabled, and the resulting binary is linked with GnuTLS.
>>
>> The “openssl” package (along with “cyrus-sasl”) was added as a new
>> input
>> to our “octave” package in commit
>> b7b27a8f28746a488eeee489c71053059dc5a8dc, along with the upgrade from
>> 4.0.0 to 4.0.2.
>>
>> I don’t know why this was done.  Maybe Kei could shed some light on
>> this.
>>
>> ~~ Ricardo
>
> When I tried to build Octave 4.0.2, the build complained about missing
> SSL and SASL libraries. Adding gnutls as a dependency (Debian users
> are advised to use libcurl4-gnutls-dev) did not fix the issue, so I
> added OpenSSL to stop the issue.

We should investigate the reason why it failed without OpenSSL.  I would
start by repeating the build attempt without OpenSSL, and looking at the
resulting config.log to see what went wrong.

> It seems to me that Octave 4.0.2 (and 4.0.3, the most recent version)
> depends on SSL for curl usage, as curl allows Octave users to issue a
> "pkg install -forge [package_name]" command to install packages from
> the Octave Forge repo. I didn't know that the licenses were
> incompatible, so now we have to name (or correctly package) the Guix
> equivalent of libcurl4-gnutls-dev.

'curl' is that package.  It is built against GnuTLS.

      Mark

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-09 17:27         ` Mike Miller
  2016-08-09 18:30           ` Ricardo Wurmus
  2016-08-10  4:23           ` Mark H Weaver
@ 2016-08-10  6:43           ` Alex Vong
  2016-08-11  6:26             ` Mike Miller
  2 siblings, 1 reply; 31+ messages in thread
From: Alex Vong @ 2016-08-10  6:43 UTC (permalink / raw)
  To: Mike Miller; +Cc: guix-devel, help-octave

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:00:59 +0800, Alex Vong wrote:
>> Hi octave devs,
>> 
>> During a look of the octave package in guix (a functional package
>> manager, part of gnu), we notice octave have an optional dependency on
>> openssl.
>> 
>> However, since the license of octave (gpl3+) is incompatible
>> with that of openssl
>> (https://people.gnome.org/~markmc/openssl-and-the-gpl.html), the
>> resulting binary after linking is not re-distributable.
>
> Agreed.
>
>> So, we drop the optional dependency to avoid the problem.
>
> Precisely what is the optional dependency that is dropped?
>
> Octave does not directly link with OpenSSL nor use any OpenSSL
> functions. The Octave package on Debian builds with all optional
> dependencies enabled, and the resulting binary is linked with GnuTLS.
>
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?

>> Is there any plan to fix this problem? There are some solutions we think
>> of: 1. add openssl linking exception to the license 2. provide support
>> for linking with gnutls as an alternative. In any case, I think we
>> should warn the user about it.
>> 
>> What are your ideas? (the messages below include the whole discussion on
>> the guix-devel mailing list)
>
> The Octave Guix package may be indirectly linking with OpenSSL through a
> direct dependency such as libcurl. I would recommend that you use a
> libcurl that is built against GnuTLS as we do on Debian.
>
Indeed, the Debian package does not depend on openssl.

> AFAICS, nothing needs to be fixed in Octave.
>
> HTH,

Thanks,
Alex

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-10  4:28               ` Mark H Weaver
@ 2016-08-11  5:56                 ` Mike Miller
  2016-08-11  9:58                   ` Mark H Weaver
  0 siblings, 1 reply; 31+ messages in thread
From: Mike Miller @ 2016-08-11  5:56 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, help-octave

On Wed, Aug 10, 2016 at 00:28:04 -0400, Mark H Weaver wrote:
> We should investigate the reason why it failed without OpenSSL.  I would
> start by repeating the build attempt without OpenSSL, and looking at the
> resulting config.log to see what went wrong.

Sounds good to me. Let us know what you find out or if there is anything
we can do to help.

-- 
mike

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-10  6:43           ` Alex Vong
@ 2016-08-11  6:26             ` Mike Miller
  2016-08-11 15:27               ` Alex Vong
  0 siblings, 1 reply; 31+ messages in thread
From: Mike Miller @ 2016-08-11  6:26 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel, help-octave

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,

-- 
mike

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-11  5:56                 ` Mike Miller
@ 2016-08-11  9:58                   ` Mark H Weaver
  0 siblings, 0 replies; 31+ messages in thread
From: Mark H Weaver @ 2016-08-11  9:58 UTC (permalink / raw)
  To: Mike Miller; +Cc: guix-devel, help-octave

Mike Miller <mtmiller@octave.org> writes:

> On Wed, Aug 10, 2016 at 00:28:04 -0400, Mark H Weaver wrote:
>> We should investigate the reason why it failed without OpenSSL.  I would
>> start by repeating the build attempt without OpenSSL, and looking at the
>> resulting config.log to see what went wrong.
>
> Sounds good to me. Let us know what you find out or if there is anything
> we can do to help.

The problem is that "-lssl -lcrypto" is apparently added to the command
line when linking liboctave.  There are no occurrences of "lssl" in the
failed octave build directory.  However, I *did* discover that
libcurl.la contains:

  dependency_libs=' [...] -lssl -lcrypto -lz'

despite the fact that our 'curl' package was built without OpenSSL.  I
guess this is the root of the problem, and that the bug is in 'curl'.

I'm not sure why this problem does not affect more packages.  Perhaps
most packages in Guix that use 'curl' either don't use libtool or
include OpenSSL as an input.  If they didn't already include OpenSSL, I
guess that maybe people "fixed" the problem by adding OpenSSL as an
input, as was done for Octave.

To be continued...

     Mark

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-11  6:26             ` Mike Miller
@ 2016-08-11 15:27               ` Alex Vong
  2016-08-11 17:04                 ` Kei Kebreau
  2016-08-12 11:45                 ` JIT compiling Jordi Gutiérrez Hermoso
  0 siblings, 2 replies; 31+ messages in thread
From: Alex Vong @ 2016-08-11 15:27 UTC (permalink / raw)
  To: Mike Miller; +Cc: Ricardo Wurmus, guix-devel, help-octave, Leo Famulari

Mike Miller <mtmiller@octave.org> 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-11 15:27               ` Alex Vong
@ 2016-08-11 17:04                 ` Kei Kebreau
  2016-08-13 12:37                   ` Alex Vong
  2016-08-12 11:45                 ` JIT compiling Jordi Gutiérrez Hermoso
  1 sibling, 1 reply; 31+ messages in thread
From: Kei Kebreau @ 2016-08-11 17:04 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel, help-octave, Mike Miller

Alex Vong <alexvong1995@gmail.com> writes:

> Mike Miller <mtmiller@octave.org> 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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* JIT compiling
  2016-08-11 15:27               ` Alex Vong
  2016-08-11 17:04                 ` Kei Kebreau
@ 2016-08-12 11:45                 ` Jordi Gutiérrez Hermoso
  2016-08-12 15:08                   ` Sergei Steshenko
  2016-08-13 12:12                   ` Alex Vong
  1 sibling, 2 replies; 31+ messages in thread
From: Jordi Gutiérrez Hermoso @ 2016-08-12 11:45 UTC (permalink / raw)
  To: Alex Vong; +Cc: guix-devel, help-octave, Mike Miller

On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
> 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.

That is a faraway pipe dream. Can you help?

- Jordi G. H.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-12 11:45                 ` JIT compiling Jordi Gutiérrez Hermoso
@ 2016-08-12 15:08                   ` Sergei Steshenko
  2016-08-12 16:06                     ` Oliver Heimlich
  2016-08-13 12:12                   ` Alex Vong
  1 sibling, 1 reply; 31+ messages in thread
From: Sergei Steshenko @ 2016-08-12 15:08 UTC (permalink / raw)
  To: Jordi Gutiérrez Hermoso, Alex Vong
  Cc: Ricardo Wurmus, guix-devel@gnu.org, Mike Miller,
	help-octave@gnu.org, Leo Famulari






>________________________________
> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>To: Alex Vong <alexvong1995@gmail.com> 
>Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
>Sent: Friday, August 12, 2016 2:45 PM
>Subject: JIT compiling
> 
>
>On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>> 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.
>
>That is a faraway pipe dream. Can you help?
>
>- Jordi G. H.
>
>


Julia ( http://julialang.org/ ) quite developed since it's been discussed here. They claim to have close to "C" performance and JIT.

And MIT (no GPL bullshit) license.

--Sergei.

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-12 15:08                   ` Sergei Steshenko
@ 2016-08-12 16:06                     ` Oliver Heimlich
  2016-08-13  1:03                       ` Sergei Steshenko
  0 siblings, 1 reply; 31+ messages in thread
From: Oliver Heimlich @ 2016-08-12 16:06 UTC (permalink / raw)
  To: Sergei Steshenko, Jordi Gutiérrez Hermoso, Alex Vong
  Cc: Ricardo Wurmus, guix-devel@gnu.org, Leo Famulari,
	help-octave@gnu.org, Mike Miller

On 12.08.2016 17:08, Sergei Steshenko wrote:
>> ________________________________
>> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>> To: Alex Vong <alexvong1995@gmail.com> 
>> Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
>> Sent: Friday, August 12, 2016 2:45 PM
>> Subject: JIT compiling
>>
>>
>> On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>> 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.
>>
>> That is a faraway pipe dream. Can you help?
>>
>> - Jordi G. H.
>>
>>
> 
> 
> Julia ( http://julialang.org/ ) quite developed since it's been discussed here. They claim to have close to "C" performance and JIT.
> 

There is a good language introduction available as a talk from JuliaCon:
https://youtu.be/rAxzR7lMGDM

As far as I can see, Julia compiles the code if it can predict the types
of the variables. Otherwise, it is slow. This is explained in the first
part of the talk.

Best
Oliver


_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-12 16:06                     ` Oliver Heimlich
@ 2016-08-13  1:03                       ` Sergei Steshenko
  2016-08-13 11:48                         ` Alex Vong
  0 siblings, 1 reply; 31+ messages in thread
From: Sergei Steshenko @ 2016-08-13  1:03 UTC (permalink / raw)
  To: Oliver Heimlich, Jordi Gutiérrez Hermoso, Alex Vong
  Cc: guix-devel@gnu.org, Mike Miller, help-octave@gnu.org





----- Original Message -----
> From: Oliver Heimlich <oheim@posteo.de>
> To: Sergei Steshenko <sergstesh@yahoo.com>; Jordi Gutiérrez Hermoso <jordigh@octave.org>; Alex Vong <alexvong1995@gmail.com>
> Cc: Ricardo Wurmus <rekado@elephly.net>; "guix-devel@gnu.org" <guix-devel@gnu.org>; Leo Famulari <leo@famulari.name>; "help-octave@gnu.org" <help-octave@gnu.org>; Mike Miller <mtmiller@octave.org>
> Sent: Friday, August 12, 2016 7:06 PM
> Subject: Re: JIT compiling
> 
> On 12.08.2016 17:08, Sergei Steshenko wrote:
> 
>>>  ________________________________
>>>  From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>>>  To: Alex Vong <alexvong1995@gmail.com> 
>>>  Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo 
> Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller 
> <mtmiller@octave.org>
>>>  Sent: Friday, August 12, 2016 2:45 PM
>>>  Subject: JIT compiling
>>> 
>>> 
>>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>>  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.
>>> 
>>>  That is a faraway pipe dream. Can you help?
>>> 
>>>  - Jordi G. H.
>>> 
>>> 
>> 
>> 
>>  Julia ( http://julialang.org/ ) quite developed since it's been 
> discussed here. They claim to have close to "C" performance and JIT.
>> 
> 
> There is a good language introduction available as a talk from JuliaCon:
> https://youtu.be/rAxzR7lMGDM
> 
> As far as I can see, Julia compiles the code if it can predict the types
> of the variables. Otherwise, it is slow. This is explained in the first
> part of the talk.
> 
> Best
> Oliver
> 


If the type can't be predicted, then runtime checks need to be made and the object might have to be recreated. E.g. if 12345678 is a number, it fits a 32 bit integer, and if it is a string, it will need 9 bytes in case of "C" representation.


So the limitation does not look to me like a Julia-specific one.

--Sergei.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-13  1:03                       ` Sergei Steshenko
@ 2016-08-13 11:48                         ` Alex Vong
  0 siblings, 0 replies; 31+ messages in thread
From: Alex Vong @ 2016-08-13 11:48 UTC (permalink / raw)
  To: Sergei Steshenko
  Cc: Jordi Gutiérrez Hermoso, help-octave@gnu.org,
	Oliver Heimlich, guix-devel@gnu.org, Mike Miller

Sergei Steshenko <sergstesh@yahoo.com> writes:

> ----- Original Message -----
>> From: Oliver Heimlich <oheim@posteo.de>
>> To: Sergei Steshenko <sergstesh@yahoo.com>; Jordi Gutiérrez Hermoso
>> <jordigh@octave.org>; Alex Vong <alexvong1995@gmail.com>
>> Cc: Ricardo Wurmus <rekado@elephly.net>; "guix-devel@gnu.org"
>> <guix-devel@gnu.org>; Leo Famulari <leo@famulari.name>;
>> "help-octave@gnu.org" <help-octave@gnu.org>; Mike Miller
>> <mtmiller@octave.org>
>> Sent: Friday, August 12, 2016 7:06 PM
>> Subject: Re: JIT compiling
>> 
>> On 12.08.2016 17:08, Sergei Steshenko wrote:
>> 
>>>>  ________________________________
>>>>  From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
>>>>  To: Alex Vong <alexvong1995@gmail.com> 
>>>>  Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo 
>> Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller 
>> <mtmiller@octave.org>
>>>>  Sent: Friday, August 12, 2016 2:45 PM
>>>>  Subject: JIT compiling
>>>> 
>>>> 
>>>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>>>  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.
>>>> 
>>>>  That is a faraway pipe dream. Can you help?
>>>> 
>>>>  - Jordi G. H.
>>>> 
>>>> 
>>> 
>>> 
>>>  Julia ( http://julialang.org/ ) quite developed since it's been 
>> discussed here. They claim to have close to "C" performance and JIT.
>>> 
>> 
>> There is a good language introduction available as a talk from JuliaCon:
>> https://youtu.be/rAxzR7lMGDM
>> 
>> As far as I can see, Julia compiles the code if it can predict the types
>> of the variables. Otherwise, it is slow. This is explained in the first
>> part of the talk.
>> 
>> Best
>> Oliver
>> 
>
>
> If the type can't be predicted, then runtime checks need to be made
> and the object might have to be recreated. E.g. if 12345678 is a
> number, it fits a 32 bit integer, and if it is a string, it will need
> 9 bytes in case of "C" representation.
>
I think in the case of jit, many of the checks can be removed by making
certain assumptions and inserts guards to check those assumptions. If
the assumptions turn out to be false, then the compiled code will be
trashed and available for jitting again.
>
> So the limitation does not look to me like a Julia-specific one.
>
> --Sergei.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-12 11:45                 ` JIT compiling Jordi Gutiérrez Hermoso
  2016-08-12 15:08                   ` Sergei Steshenko
@ 2016-08-13 12:12                   ` Alex Vong
  2016-08-14  8:07                     ` Sergei Steshenko
  1 sibling, 1 reply; 31+ messages in thread
From: Alex Vong @ 2016-08-13 12:12 UTC (permalink / raw)
  To: Jordi Gutiérrez Hermoso
  Cc: Ricardo Wurmus, guix-devel, Leo Famulari, help-octave,
	Mike Miller

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>> 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.
>
> That is a faraway pipe dream. Can you help?
>
I think I will be too un-experienced to help, but I am interested in
it. I've always dreamt octave having good anoymous and nested function
support. I think the first step is to prase octave correctly. Is there a
reference on it other than the libinterp code itself?

> - Jordi G. H.

Cheers,
Alex

_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: octave license is incompatible with openssl
  2016-08-11 17:04                 ` Kei Kebreau
@ 2016-08-13 12:37                   ` Alex Vong
  0 siblings, 0 replies; 31+ messages in thread
From: Alex Vong @ 2016-08-13 12:37 UTC (permalink / raw)
  To: Kei Kebreau; +Cc: guix-devel, help-octave, Mike Miller

Kei Kebreau <kei@openmailbox.org> writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Mike Miller <mtmiller@octave.org> 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-13 12:12                   ` Alex Vong
@ 2016-08-14  8:07                     ` Sergei Steshenko
  2016-08-14 10:21                       ` Francesco Potortì
  2016-08-14 20:20                       ` Jordi Gutiérrez Hermoso
  0 siblings, 2 replies; 31+ messages in thread
From: Sergei Steshenko @ 2016-08-14  8:07 UTC (permalink / raw)
  To: Alex Vong, Jordi Gutiérrez Hermoso
  Cc: guix-devel@gnu.org, Mike Miller, help-octave@gnu.org





----- Original Message -----
> From: Alex Vong <alexvong1995@gmail.com>
> To: Jordi Gutiérrez Hermoso <jordigh@octave.org>
> Cc: Ricardo Wurmus <rekado@elephly.net>; guix-devel@gnu.org; Leo Famulari <leo@famulari.name>; help-octave@gnu.org; Mike Miller <mtmiller@octave.org>
> Sent: Saturday, August 13, 2016 3:12 PM
> Subject: Re: JIT compiling
> 
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
>>  On Thu, 2016-08-11 at 23:27 +0800, Alex Vong wrote:
>>>  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.
>> 
>>  That is a faraway pipe dream. Can you help?
>> 
> I think I will be too un-experienced to help, but I am interested in
> it. I've always dreamt octave having good anoymous and nested function
> support. I think the first step is to prase octave correctly. Is there a
> reference on it other than the libinterp code itself?
> 
>>  - Jordi G. H.
> 
> Cheers,
> 
> Alex
> 
> _______________________________________________
> Help-octave mailing list
> Help-octave@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-octave

> 


"I've always dreamt octave having good anoymous and nested function

support" - then switch to Perl -> PDL (http://pdl.perl.org/) or OCaml (if you want type strictness and near "C" performance).

...

When Julia language was first discussed here, I suggested to write an Octave -> Julia translator, but I think it will NEVER be done for ideological (fanatic support of false/fake GPL freedom) reasons.


The rationale was to get the best of the two worlds - speed of Julia and packages available for Octave - in addition to what already exists for Julia.

--Sergei.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-14  8:07                     ` Sergei Steshenko
@ 2016-08-14 10:21                       ` Francesco Potortì
  2016-08-14 20:20                       ` Jordi Gutiérrez Hermoso
  1 sibling, 0 replies; 31+ messages in thread
From: Francesco Potortì @ 2016-08-14 10:21 UTC (permalink / raw)
  To: Sergei Steshenko
  Cc: Alex Vong, Leo Famulari, Ricardo Wurmus, help-octave@gnu.org,
	guix-devel@gnu.org, Mike Miller

>When Julia language was first discussed here, I suggested to write an
>Octave -> Julia translator, but I think it will NEVER be done for
>ideological (fanatic support of false/fake GPL freedom) reasons.

Sergei,

you had stopped for a while insulting the Octave developers and the free
software community.  That was a good thing.  However, this is your
second message in few days that brings back your old habits.  You can do
better.  Please do.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it


_______________________________________________
Help-octave mailing list
Help-octave@gnu.org
https://lists.gnu.org/mailman/listinfo/help-octave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: JIT compiling
  2016-08-14  8:07                     ` Sergei Steshenko
  2016-08-14 10:21                       ` Francesco Potortì
@ 2016-08-14 20:20                       ` Jordi Gutiérrez Hermoso
  1 sibling, 0 replies; 31+ messages in thread
From: Jordi Gutiérrez Hermoso @ 2016-08-14 20:20 UTC (permalink / raw)
  To: Sergei Steshenko; +Cc: help-octave@gnu.org, guix-devel@gnu.org, Mike Miller

Hi, Sergei. Haven't spoken in a while.

On Sun, 2016-08-14 at 08:07 +0000, Sergei Steshenko wrote:

> When Julia language was first discussed here, I suggested to write
> an Octave -> Julia translator, but I think it will NEVER be done for
> ideological (fanatic support of false/fake GPL freedom) reasons.

The complete Julia package is GPL'ed because Julia uses popular GPL
libraries such as FFTW, Suitesparse, and readline. We're on good terms
with the Julia developers and they do not have a problem with the GPL.

The reason the Octave -> Julia translator hasn't happened is because
it's not a problem that's significantly different than compiling
Octave into any other language that has a type declarations.

- Jordi G. H.

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2016-08-14 20:21 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-04 16:35 octave license is incompatible with openssl Alex Vong
2016-08-04 17:10 ` John Darrington
2016-08-04 17:20   ` ng0
2016-08-05  9:08     ` Alex Vong
2016-08-05  9:03   ` Alex Vong
2016-08-05 11:43     ` Mathieu Lirzin
2016-08-05  6:50 ` Ricardo Wurmus
2016-08-06  1:52   ` Alex Vong
2016-08-08 20:00     ` Leo Famulari
2016-08-09 16:00       ` Alex Vong
2016-08-09 17:27         ` Mike Miller
2016-08-09 18:30           ` Ricardo Wurmus
2016-08-09 21:33             ` kei
2016-08-10  4:28               ` Mark H Weaver
2016-08-11  5:56                 ` Mike Miller
2016-08-11  9:58                   ` Mark H Weaver
2016-08-10  4:23           ` Mark H Weaver
2016-08-10  6:43           ` Alex Vong
2016-08-11  6:26             ` Mike Miller
2016-08-11 15:27               ` Alex Vong
2016-08-11 17:04                 ` Kei Kebreau
2016-08-13 12:37                   ` Alex Vong
2016-08-12 11:45                 ` JIT compiling Jordi Gutiérrez Hermoso
2016-08-12 15:08                   ` Sergei Steshenko
2016-08-12 16:06                     ` Oliver Heimlich
2016-08-13  1:03                       ` Sergei Steshenko
2016-08-13 11:48                         ` Alex Vong
2016-08-13 12:12                   ` Alex Vong
2016-08-14  8:07                     ` Sergei Steshenko
2016-08-14 10:21                       ` Francesco Potortì
2016-08-14 20:20                       ` Jordi Gutiérrez Hermoso

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).