* 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 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-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-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-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-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 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-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-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-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 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 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 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
* 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
* 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: 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).