Create a giac package

[frederichan]

The build of the GUI (xcas) has been disabled in the spkg-install to minimize the dependencies.

Sage packages:

• ​http://webusers.imj-prg.fr/~frederic.han/xcas/sage/giac-1.2.0.13.tar.gz
• ​http://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy-0.4.8.tar.gz

---

The Sage giac package was built with spkg-src from the original giac 1.2.0-13 source: ​http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.2.0-13.tar.gz

---

giacpy-sage git repository: ​https://gitlab.math.univ-paris-diderot.fr/han/giacpy-sage
worksheets and pdf examples ​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/

Some interresting applications

• Grobner basis (revlex) over QQ and Zp (+ some multithreadings).

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/grobner-libgiac.sws or ​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/grobner-libgiac.pdf

• Benchmarking for computing a QQ Groebner Basis of cyclic9 from sage with magma/giacpy+multithreads, and testing savegen/loadgiacgen with this computation (Wall time 7h, Ram 7Go, File 1.1Go).

​http://webusers.imj-prg.fr/~frederic.han/xcas/giacpy/index.html#cyclic9

• Some computations (determinant, simplifications...) with many variables. Ex

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/giacpy-cubics.sws or ​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/giacpy-cubics.pdf

• Symbolic calculus. Ex solving some inequalities, but also some primitive may be more lucky (cf the constant term in ​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/plot-libgiac.pdf)
  

[frederichan]

a copy of the SPKG.txt file included.

[frederichan]

-update to giac 0.9.6

-The CFLAGS and CXXFLAGS settings in spkg-install had been removed because it was not necessary to force their values.

[frederichan]

The 0.9.6 had a bad choice of algorithm with big polynomials. Ex the test with (x+y+z+1)^n+1. for n>34.

[jdemeyer]

Please fill in your real name as Author.

[frederichan]

Updated to giac 0.9.8 (current stable) ​http://people.math.jussieu.fr/~han/xcas/giac-0.9.8.spkg

[frederichan]

upgrade the spkg to the current version of giac: 1.0.0

[frederichan]

Update to version 1.1 of giac.

​http://www.math.jussieu.fr/~han/xcas/sage/giac-1.1.0.spkg

I have disabled pari in this spkg to avoid conflicts when using the giac library from cython such as in giacpy. (cf ​http://www.math.jussieu.fr/~han/xcas/giacpy/)

[jondo]

Would this make giac available in the provided Sage VMs?

(Context: ​Solving rational inequality should give simplified result)

[frederichan]

Replying to jondo:

Would this make giac available in the provided Sage VMs?

(Context: ​Solving rational inequality should give simplified result)

I believe that these examples are using the pexpect (communications through string) giac interface that is already in sage. So you just need an external giac program in your path. It could be installed from this spkg but by other ways also.

But you also need to create the following directory in you sage install:

sage/local/share/sage/ext/giac and sage/local/share/sage/ext/giac/user

I have added a new version of the spkg with 1.1.1 giac sources. ​http://www.math.jussieu.fr/~han/xcas/sage/giac-1.1.1.spkg

Best regards

[jondo]

In the mentioned sage-devel thread Dima Pasechnik asked: "Was there a vote carried out for inclusion of such an spkg?"

[dimpase]

There are C++ errors when I try building this. One should use ​http://www.cplusplus.com/reference/unordered_map/unordered_map/ nowadays, not hash_map, which is gone for good.

See the attached log.

[dimpase]

log of the build attempt (on Sage 6.3.beta5), OSX 10.9

[frederichan]

Replying to dimpase:

There are C++ errors when I try building this. One should use ​http://www.cplusplus.com/reference/unordered_map/unordered_map/ nowadays, not hash_map, which is gone for good.

See the attached log.

Thank you for the feedback, I have reported this upstream because it is not a typical problem of the spkg. ​http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1518

Best regards, Frederic

[vbraun]

Since there is a Cython interface it would be much preferable to include that. Expect is always slow and prone to pty/synchronization bugs.

[frederichan]

Of course I agree that its better to have a cython interface, Feel free to add your comments on it here

​http://trac.sagemath.org/ticket/15226

I will be happy to have feedback and help! NB: I'am leaving in vacation tonight with bad or no internet, but after I will be happy to work on this

[frederichan]

I have updated the giac spkg to the current giac version (1.1.2 testing) but I have tested this only on linux, in particular I don't have informations on os 10.9 (although I can compile this giac version on freebsd11) ​https://www.imj-prg.fr/~frederic.han/xcas/sage/giac-1.1.2.spkg

I have also done an spkg of the cython interface and called it giacpy. ​https://www.imj-prg.fr/~frederic.han/xcas/sage/giacpy-0.4.spkg

sample test:

from giacpy import *
libgiac.solve(x-x*exp(x/100-1)>0, x)

should give:

list[((x>0) and (x<100))]

[dimpase]

Replying to Han Frederic:

I have updated the giac spkg to the current giac version (1.1.2 testing) but I have tested this only on linux, in particular I don't have informations on os 10.9 (although I can compile this giac version on freebsd11)

It does not work on OSX 10.9, with "standard" Sage complier, i.e. gcc 4.7.3. I still get things like

index.h:559:11: error: 'hash_map' in namespace 'std' does not name a type

(I also tried on Linux with gcc 4.8.something, and it worked there) I'll try the experimental Sage gcc 4.8.1 package, see if it helps.

[frederichan]

thank you, it could be a configure problem. could you have a look in your src/src/config.h about the values of this define

/* Define if <unordered_map> header is available */
#define C11_UNORDERED_MAP 1

...

/* Define if <ext/hash_map> header is aviailable */
#define EXT_HASH_MAP 1

/* Define if <hash_map> header is aviailable */
/* #undef HASH_MAP */

...

/* Define if <tr1/unordered_map> header is available */
#define UNORDERED_MAP 1

or try to force to

#include <unordered_map>

in src/src/index.h to see if the compilation goes on?

[dimpase]

Replying to Han Frederic:

thank you, it could be a configure problem. could you have a look in your src/src/config.h about the values of this define

/* Define if <unordered_map> header is available */
#define C11_UNORDERED_MAP 1

...

/* Define if <ext/hash_map> header is aviailable */
#define EXT_HASH_MAP 1

/* Define if <hash_map> header is aviailable */
/* #undef HASH_MAP */

...

/* Define if <tr1/unordered_map> header is available */
#define UNORDERED_MAP 1

the 1st of these is undefined, the rest are defined in my case.

Probably your (and Redhat's) version of g++ is somehow different from the "normal" g++, and this makes the difference.

by the way, ​https://www.imj-prg.fr/~frederic.han/xcas/sage/giac-1.1.2.spkg is down. Could you host it somewhere else?

[frederichan]

On linux ubuntu 12.04 with gcc I have the same config.h as yours. (the previous config posted was with clang on freebsd, sorry I though it was closer to yours)

But I could have the same error as yours on os 10.7 with sage 5.6 and the sage gcc. I believe that the problem is this !defined(APPLE) line 47 of index.h

#if defined UNORDERED_MAP && !defined(__APPLE__) && !defined(__clang__) && !defined(VISUALC)

so it blocks the use of tr1/unordered_map.

I'have got success with the spkg and sage 5.6 on os 10.7 by changing line 47 with:

#if defined UNORDERED_MAP && !defined(__clang__) && !defined(VISUALC)

does it works for you also?

NB: The link seems repaired, sorry I still have bad internet now.

[dimpase]

Replying to Han Frederic:

On linux ubuntu 12.04 with gcc I have the same config.h as yours. (the previous config posted was with clang on freebsd, sorry I though it was closer to yours)

But I could have the same error as yours on os 10.7 with sage 5.6 and the sage gcc. I believe that the problem is this !defined(APPLE) line 47 of index.h

#if defined UNORDERED_MAP && !defined(__APPLE__) && !defined(__clang__) && !defined(VISUALC)

so it blocks the use of tr1/unordered_map.

I'have got success with the spkg and sage 5.6 on os 10.7 by changing line 47 with:

#if defined UNORDERED_MAP && !defined(__clang__) && !defined(VISUALC)

does it works for you also?

yes it does.

The spkg still needs a bit of cleaning though. Also, currently it is an "old style" spkg.

If there is a "canonical" version of giac-1.1.2 somewhere it's better to provide it as the upstream tarball, and create patches; this is the "new style" of spkgs. See ​http://sagemath.org/doc/developer/packaging.html

[frederichan]

hello, so I have worked (and generated checksums) with the following upstream source

​http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.1.1.tar.gz

(closed the 9 july 2014) because the 1.1.2 file will still evolve.

I have put the spkg scripts there:

​https://www.imj-prg.fr/~frederic.han/xcas/sage/giac.tar.bz2

For the cython interface giacpy, I have put the upstream source file:

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy-0.4.tar.gz

and the spkg scripts there:

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy.tar.bz2

is it the correct way to distribute new spkg?

I got success with sage 6.2 on ubuntu 12.04 amd64 and osx 10.7.

[dimpase]

Replying to Han Frederic:

hello, so I have worked (and generated checksums) with the following upstream source

​http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.1.1.tar.gz

(closed the 9 july 2014) because the 1.1.2 file will still evolve.

I have put the spkg scripts there:

​https://www.imj-prg.fr/~frederic.han/xcas/sage/giac.tar.bz2

For the cython interface giacpy, I have put the upstream source file:

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy-0.4.tar.gz

and the spkg scripts there:

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy.tar.bz2

is it the correct way to distribute new spkg?

Did you look at

​http://sagemath.org/doc/developer/packaging.html

The scripts should come as a git branch for the Sage git tree, so that they can be "installed" by doing git checkout, more or less, and certainly not by untarring tarballs...

[frederichan]

u/Han Frederic/submit_a_giacspkg

[frederichan]

Sorry for this mess with the git branch, but I am lost. I first could do:

git trac checkout 12375

but I failed to push (I though it was a space problem so I tried to change the branch name) but now I have a Couldn't find remote ref public/giac_spkg

I have also tried to create a new one with:

git trac create 'giac new style spkg' -b public/giac_spkg

(ticket 16771) and I could do: git trac checkout 16771

but when I do

git trac push

I have:

Pushing to Trac #16771...
Guessed remote branch: u/Han Frederic/giac_new_style_spkg
Traceback (most recent call last):
  File "/usr/local/sage-6.2/local/bin/git-trac", line 18, in <module>
    cmdline.launch()
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/cmdline.py", line 132, in launch
    app.push(ticket_number)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/app.py", line 147, in push
    self.repo.push(remote)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_repository.py", line 150, in push
    self.git.echo.push('trac', 'HEAD:'+remote_branch)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 355, in meth
    return self.execute(git_cmd, *args, **kwds)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 98, in execute
    popen_stderr=subprocess.PIPE)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 262, in _run
    raise GitError(result)
git_trac.git_error.GitError: git returned with non-zero exit code (128) when executing "git push trac HEAD:u/Han Frederic/giac_new_style_spkg"
    STDERR: fatal: remote part of refspec is not a valid name in HEAD:u/Han Frederic/giac_new_style_spkg

[dimpase]

Do you use git trac extension (​https://github.com/sagemath/git-trac-command) ?

Do you have your ssh key etc already uploaded to trac, and are able to checkout stuff?

If this is working, the usual guess would be that one cannot have a space in the branch name. You may try pushing to public/blah instead.

[frederichan]

Yes I have used git-trac and uploaded my pub key, but most likely I have an ssh problem. I have made many tries, and may be my key manager started to offer the bad keys but now here is my last situation from start:

macbookito(fred)$ git-trac config --user 'Han Frederic' --pass 'XXXXXXXXXX'
Saved trac username.
Saved trac password.
Trac xmlrpc URL:
    http://trac.sagemath.org/xmlrpc (anonymous)
    http://trac.sagemath.org/login/xmlrpc (authenticated)
    realm sage.math.washington.edu
Username: Han Frederic
Password: XXXXXXXXX
Retrieving SSH keys...
    2048 b4:a3:58:12:d8:ae:5d:51:36:1b:99:4b:77:1a:d3:b9  fred@macbookito (RSA)
macbookito(fred)$ git remote -v
origin	https://github.com/sagemath/git-trac-command.git (fetch)
origin	https://github.com/sagemath/git-trac-command.git (push)
trac	git://trac.sagemath.org/sage.git (fetch)
trac	git@trac.sagemath.org:sage.git (push)
macbookito(fred)$ 

so trac found my public key and to check that I have the corresponding private key:

macbookito(fred)$ ssh-keygen -l 
Enter file in which the key is (/home/fred/.ssh/id_rsa): /home/fred/.ssh/id_rsa-trac
2048 b4:a3:58:12:d8:ae:5d:51:36:1b:99:4b:77:1a:d3:b9  fred@macbookito (RSA)

but if I try to test ssh as in the sage doc the offering key fails

macbookito(fred)$ ssh -v -i ~/.ssh/id_rsa-trac git@trac.sagemath.org info
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/fred/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to trac.sagemath.org [128.208.178.249] port 22.
debug1: Connection established.
debug1: identity file /home/fred/.ssh/id_rsa-trac type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/fred/.ssh/id_rsa-trac-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.3
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 21:ba:10:2a:59:cd:7d:36:f7:4c:52:bf:fc:5e:0e:07
debug1: Host 'trac.sagemath.org' is known and matches the ECDSA host key.
debug1: Found key in /home/fred/.ssh/known_hosts:54
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/fred/.ssh/id_rsa-trac
debug1: Authentications that can continue: publickey,password
...

could my key manager (during my first tries) had started to offer too many bad keys so that I am blacklisted or I may have miss some config problem.

[dimpase]

So you never see

debug1: Server accepts key: ...

in the log above?

When I try the same, I see

debug1: Server host key: RSA 97:e0:9a:4e:40:7f:00:63:f7:b9:e6:cf:dd:cb:d2:6c

seems like we are connecting to different ssh servers...

[dimpase]

The RSA/ECDSA thing was due to me having stored the RSA key of the host previously. Nothing weird here...

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9562050

add giac and giacpy pkg scripts

[dimpase]

to get giac to compile on my Debian system, I had to

apt-get install libtool gettext

Is this (more precisely, what extra libs need to be installed, compared to the standard Sage setup) mentioned in the spkg docs?

In giac's SPKG.txt I see

== Dependencies == 
  * gettext, readline, gmp 
  * giac will benefits of ntl, pari, mpfr, gsl, lapack but they should be already installed by sage.

gmp (more precisely, its clone) is provided by Sage (and so it should be removed from the fist *'d line.

the 2nd *'d line has a typo: "benefits" -> "benefit"

[dimpase]

sage -t --optional=sage,giac src/sage/interfaces/giac.py

produces several errors:

**********************************************************************
File "src/sage/interfaces/giac.py", line 38, in sage.interfaces.giac
Failed example:
    giac.fsolve('x^2=cos(x)+4', 'x','0..5')         # optional - giac
Expected:
    1.9140206190...
Got:
    [1.91402061903]
**********************************************************************
File "src/sage/interfaces/giac.py", line 229, in sage.interfaces.giac.Giac
Failed example:
    giac('assume(y>0)'); giac('y^2=3').solve('y')  #optional - giac
Expected:
    y
    [sqrt(3)]
Got:
    y
    list[sqrt(3)]
**********************************************************************
File "src/sage/interfaces/giac.py", line 257, in sage.interfaces.giac.Giac
Failed example:
    a=sqrt(2);giac('Digits:=30;a:=5');a,giac('a'),giac(a),giac(a).evalf()  # optional - giac
Expected:
    [...]
    (sqrt(2), 5, sqrt(2), 1.414213562373095048801688724209)
Got:
    30
    (sqrt(2), 5, sqrt(2), 1.41421356237309504880168872421)
**********************************************************************
File "src/sage/interfaces/giac.py", line 309, in sage.interfaces.giac.Giac._keyboard_interrupt
Failed example:
    try:                                   # optional - giac
        giac._keyboard_interrupt()
    except KeyboardInterrupt:
        pass
Exception raised:
    Traceback (most recent call last):
      File "/home/dima/sage/sage-6.3.beta7/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 480, in _run
        self.execute(example, compiled, test.globs)
      File "/home/dima/sage/sage-6.3.beta7/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 839, in execute
        exec compiled in globs
      File "<doctest sage.interfaces.giac.Giac._keyboard_interrupt[1]>", line 2, in <module>
        giac._keyboard_interrupt()
      File "/home/dima/sage/sage-6.3.beta7/local/lib/python2.7/site-packages/sage/interfaces/giac.py", line 322, in _keyboard_interrupt
        raise RuntimeError("Ctrl-c pressed while running %s"%self)
    RuntimeError: Ctrl-c pressed while running Giac
**********************************************************************
File "src/sage/interfaces/giac.py", line 986, in sage.interfaces.giac.GiacElement._latex_
Failed example:
    print latex(giac('(x^4 - y)/(y^2-3*x)'))      # optional - giac
Expected:
    "\frac{(x^{4}-y)}{(y^{2}-3 x)}"
Got:
    "\frac{(x^{4}-y)}{(y^{2}-3\cdot x)}"
**********************************************************************
File "src/sage/interfaces/giac.py", line 1042, in sage.interfaces.giac.GiacElement._sage_
Failed example:
    m.trigexpand().sage()                              # optional - giac
Expected:
    2*(cos(1/x) - 1)^2*sin(sqrt(-x^2 + 1))*cos(sqrt(-x^2 + 1))
Got:
    2*cos(sqrt(-x^2 + 1))*cos(1/x)^2*sin(sqrt(-x^2 + 1)) - 4*cos(sqrt(-x^2 + 1))*cos(1/x)*sin(sqrt(-x^2 + 1)) + 2*cos(sqrt(-x^2 + 1))*sin(sqrt(-x^2 + 1))
**********************************************************************
File "src/sage/interfaces/giac.py", line 1084, in sage.interfaces.giac.GiacElement.integral
Failed example:
    f.evalf(100)                                              # optional - giac
Expected:
    1.4626517459071819025155758073473096674669301007326185820691973210905694258465619632003390265815626744
Got:
    1.4626517459072
**********************************************************************
6 items had failures:
   1 of  22 in sage.interfaces.giac
   2 of  12 in sage.interfaces.giac.Giac
   1 of   4 in sage.interfaces.giac.Giac._keyboard_interrupt
   1 of   2 in sage.interfaces.giac.GiacElement._latex_
   1 of   5 in sage.interfaces.giac.GiacElement._sage_
   1 of   6 in sage.interfaces.giac.GiacElement.integral
    [159 tests, 7 failures, 3.36 s]
----------------------------------------------------------------------
sage -t src/sage/interfaces/giac.py  # 7 doctests failed

they should be fixed there.

[frederichan]

Yes I can reproduce all these diffs outside sage so it is not a problem of the spkg. For the loss in precision I have reported it on xcas forum to know if it is a long term change or a bug so I wait a little to know if it should be changed in giac.py.

But I have also looked at the cython interface and I found a problem that I didn't have with sage 5.11.

in the .pyx module I did:

cdef extern from "csage/interrupt.h":
    void setup_sage_signal_handler "setup_sage_signal_handler"()
setup_sage_signal_handler()

and it worked fine with sage 5.11. But with my sage 6.2, even if I do this in an empty module tutu.pyx, then after doing in sage:

import tutu

hitting a control-c in the prompt quits sage. Is there some way to set the good signal handler for interruptions?

[dimpase]

Replying to frederichan:

Yes I can reproduce all these diffs outside sage so it is not a problem of the spkg. For the loss in precision I have reported it on xcas forum to know if it is a long term change or a bug so I wait a little to know if it should be changed in giac.py.

you can just set up higher tolerance in the corresponding doctests.

But I have also looked at the cython interface and I found a problem that I didn't have with sage 5.11.

in the .pyx module I did:

cdef extern from "csage/interrupt.h":
    void setup_sage_signal_handler "setup_sage_signal_handler"()
setup_sage_signal_handler()

and it worked fine with sage 5.11. But with my sage 6.2, even if I do this in an empty module tutu.pyx, then after doing in sage:

import tutu

hitting a control-c in the prompt quits sage. Is there some way to set the good signal handler for interruptions?

did you check in ​http://www.sagemath.org/doc/developer/coding_in_cython.html#interrupt-and-signal-handling

It could be that things got changed there since 5.11 (I don't know for sure; ask on sage-develop if problems persist here). Do you do sign_on and sign_off ?

[jdemeyer]

Replying to frederichan:

In the .pyx module I did:

cdef extern from "csage/interrupt.h":
    void setup_sage_signal_handler "setup_sage_signal_handler"()
setup_sage_signal_handler()

Delete that and try again. Let me know if it still doesn't work.

Of course you need to add sig_on() and sig_off() around the C function calls, as explained in ​http://www.sagemath.org/doc/developer/coding_in_cython.html#using-sig-on-and-sig-off

[frederichan]

Thank you for your answers, I have found more hints. In fact it is not a problem of sage 5.11 versus sage 6.2 but:

If giac is compiled without pari support then all is fine (without setup_sage_signal_handler()) while if I compile giac with pari support then I have the following problem (after hitting control-c).

sage: import giacpy
// Giac share root-directory:/usr/local/sage-6.2/local/share/giac/
// Using keyword file /usr/local/sage-6.2/local/share/giac/doc/fr/keywords
// Giac share root-directory:/usr/local/sage-6.2/local/share/giac/
Help file /usr/local/sage-6.2/local/share/giac/doc/fr/aide_cas not found
Added 0 synonyms
sage:   ***   user interrupt.

so it seems that my problem is that pari got the signal (there is no such message in giac sources). is there a way to restore the signal to sage?

[jdemeyer]

Please add a link to the correct giac tarball in the ticket description, such that I can at least try it.

[jdemeyer]

I don't know how giac uses PARI, but I assume that giac initializes the PARI library and that would certainly conflict with Sage's use of PARI.

[frederichan]

Yes it initializes PARI library, so if there are too many conflicts I will disable pari in the giac spkg.

[jdemeyer]

I notice your package does

aclocal
autoconf
automake --add-missing
libtoolize

however, these tools are normally not installed. The "solution" is to distribute patches also to the generated files like configure.

[jdemeyer]

My installation of your giac package fails with

make  all-recursive
make[1]: Entering directory `/usr/local/src/sage-config/local/var/tmp/sage/build/giac-1.1.1/src'
Making all in src
make[2]: Entering directory `/usr/local/src/sage-config/local/var/tmp/sage/build/giac-1.1.1/src/src'
/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..  -DIN_GIAC -I. -I.. -I. -I..       -g -O2  -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -MT input_lexer.lo -MD -MP -MF .deps/input_lexer.Tpo -c -o input_lexer.lo input_lexer.cc
libtool: Version mismatch error.  This is libtool 2.4, but the
libtool: definition of this LT_INIT comes from libtool 2.2.4.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4
libtool: and run autoconf again.
make[2]: *** [input_lexer.lo] Error 63
make[2]: Leaving directory `/usr/local/src/sage-config/local/var/tmp/sage/build/giac-1.1.1/src/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/sage-config/local/var/tmp/sage/build/giac-1.1.1/src'
make: *** [all] Error 2

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ee032bf	-Remove the config.in patch. So remove also the reconfiguration steps in spkg-install.
​94cc750	disable pari support to compile the c++ libgiac and modify checks accordingly
​753d8d9	update to giacpy 0.4.1 version. (version of giacpy without setup_sage_signal_handler)
​ee6258d	Fixes in the pexpect giac interfaces doctests.

[jdemeyer]

There is no need to keep old patches or to keep old # commented code, that's why we have version control. One can always go back to the old versions if needed.

[jdemeyer]

Also, patches should apply without fuzz, especially fuzz 2 is dangerous:

Applying patches...
patching file src/index.h
Hunk #1 succeeded at 35 with fuzz 2.
patching file check/TP00-sol.cas.out1
patching file check/TP02-sol.cas.out1
patching file check/TP09-sol.cas.out1
patching file check/TP19-sol.cas.out1
patching file check/geo.out
patching file check/TP04-sol.cas
patching file check/TP06-sol.cas
patching file check/TP08-sol.cas.out1
patching file check/TP11-sol.cas.out1
patching file check/TP12-sol.cas.out1
patching file check/TP13-sol.cas.out1

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d1b5cfd

clean commented code, unapplied patches and fuz in patch

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​12dff8c

update to giacpy 0.4.2. New features in the upstream tar ball:

[dimpase]

Looks good to me.

Jeroen, how does it look for you?

[jdemeyer]

This should be changed to optional - giac and properly formatted like the other docstrings:

        """
        EXAMPLES:
            sage: l = giac([1,2,3]) #optional
            sage: list(iter(l))          #optional
            [1, 2, 3]
        """

[jdemeyer]

In spkg-install you should properly document the reason why you add --disable-pari: the reason is that giac initializes the PARI library and Sage also does the same thing, leading to conflicts (these conflicts include but are not limited to interrupts).

As I said before, I don't like commented out code like

#./configure --prefix="$SAGE_LOCAL" --disable-gui --disable-gmpxx

There is also this line:

echo >&2 "Error installing libGAP."

In the giacpy spkg-install, you can remove

sage setup.py build_ext


if [ $? -ne 0 ]; then
    exit 1
fi

[jdemeyer]

There are 2 other doctest failures:

sage -t src/sage/calculus/calculus.py
**********************************************************************
File "src/sage/calculus/calculus.py", line 587, in sage.calculus.calculus.symbolic_sum
Failed example:
    symbolic_sum(1/(1+k^2), k, -oo, oo, algorithm = 'giac')           # optional - giac
Expected:
    -(pi*e^(-2*pi) - pi*e^(2*pi))/(e^(-2*pi) + e^(2*pi) - 2)
Got:
    (pi*e^(2*pi) - pi*e^(-2*pi))/(e^(2*pi) + e^(-2*pi) - 2)
**********************************************************************

sage -t src/sage/symbolic/expression.pyx
**********************************************************************
File "src/sage/symbolic/expression.pyx", line 10102, in sage.symbolic.expression.Expression.sum
Failed example:
    (sum(1/(1+k^2), k, -oo, oo, algorithm = 'giac')).factor()       # optional - giac
Expected:
    (e^(2*pi) + 1)*pi/((e^pi - 1)*(e^pi + 1))
Got:
    pi*(e^(2*pi) + 1)/((e^pi + 1)*(e^pi - 1))
**********************************************************************

There are also some giac tests in src/sage/matrix/matrix1.pyx and src/sage/modules/free_module_element.pyx which should be marked

# optional - giac

instead of #optional.

[jdemeyer]

Side comment about PARI support: it should be possible to patch giac such that it uses PARI without initializing PARI.

[frederichan]

Thank you for your comments. I have asked B. Parisse to consider to offer the possibility to not initialize pari, it would be better to do this upstream. But with the current version of giac I have not noticed a loss of performance in symbolic computations, grobner basis... with --disable-pari.

I have also found a (minimal) conversion from giac to SR that the pexpect interface can do and not giacpy, so I plan to add this.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​90ab5ed	clean up other versions of giacpy before installation.
​d0d9d47	Update comments in the giac pkg.
​ae47680	remove unecessary lines in giacpy spkg-install
​88d4983	Fixes in doctests of the pexpect giac interface

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​761bcc1

update to giacpy 0.4.3. upstream changes:

[frederichan]

a copy of the giacpy 0.4.2 vs 0.4.3 diff file:

​https://www.imj-prg.fr/~frederic.han/xcas/giacpy/sage/giacpy-0.4.2_0.4.3.diff

[frederichan]

Hello, about pari support in the giac spkg. I saw your thread on pari-devel and made some tests.

with the following patch for giac:

--- a/src/pari.cc	2014-07-02 11:05:07.000000000 +0200
+++ b/src/pari.cc	2014-10-03 17:21:23.000000000 +0200
@@ -96,7 +96,7 @@
 
   struct giac_pari_init {
     giac_pari_init(long maxprime) { 
-      do_giac_pari_init(maxprime);
+      if(!avma){ do_giac_pari_init(maxprime);}
     }
   };
   static long pari_maxprime=100000;

and some modifications in giacpy (because giac has an internal lock for pari, and it had to be resetted after an interruption) I can experience good results (both with giacpy and the external giac) So I'd like to know how do you deal with the other similar situations to be coherent.

For the giac spkg, I believe that disabling pari for 1 year is not a big problem. Or whould you prefer some environment variable to let the choice during the install step? (But my feeling is that nobody will notice this possibility)

Cheers

[jdemeyer]

Replying to frederichan:

Hello, about pari support in the giac spkg. I saw your thread on pari-devel and made some tests.

with the following patch for giac:

--- a/src/pari.cc	2014-07-02 11:05:07.000000000 +0200
+++ b/src/pari.cc	2014-10-03 17:21:23.000000000 +0200
@@ -96,7 +96,7 @@
 
   struct giac_pari_init {
     giac_pari_init(long maxprime) { 
-      do_giac_pari_init(maxprime);
+      if(!avma){ do_giac_pari_init(maxprime);}
     }
   };
   static long pari_maxprime=100000;

Has this patch been submitted upstream to giac? If not, please do that and put a link to your upstream report on this ticket.

For the giac spkg, I believe that disabling pari for 1 year is not a big problem.

Why 1 year?

Or whould you prefer some environment variable to let the choice during the install step?

No.

[frederichan]

Replying to jdemeyer:

Replying to frederichan:

Hello, about pari support in the giac spkg. I saw your thread on pari-devel and made some tests.

with the following patch for giac:

--- a/src/pari.cc	2014-07-02 11:05:07.000000000 +0200
+++ b/src/pari.cc	2014-10-03 17:21:23.000000000 +0200
@@ -96,7 +96,7 @@
 
   struct giac_pari_init {
     giac_pari_init(long maxprime) { 
-      do_giac_pari_init(maxprime);
+      if(!avma){ do_giac_pari_init(maxprime);}
     }
   };
   static long pari_maxprime=100000;

Has this patch been submitted upstream to giac? If not, please do that and put a link to your upstream report on this ticket.

So I have submitted it: ​http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1539

The current status is that the patch is included in the upstream source 1.1.2 08-Oct-2014 16:45. (it is not a frozen source)

​http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.1.2.tar.gz

For the giac spkg, I believe that disabling pari for 1 year is not a big problem.

Why 1 year?

Well it was just a rough estimate because one year ago I didn't knew any giac functions using pari that were not already in sage via pari. But now I saw some solve and resultant are also using pari, and I believe that it will increase.

Or whould you prefer some environment variable to let the choice during the install step?

No.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3874ac2

Enable pari support in the spkg, and update giacpy accordingly.

[frederichan]

New commits:

​3874ac2

Enable pari support in the spkg, and update giacpy accordingly.

[jdemeyer]

Replying to frederichan:

it is not a frozen source

What does this sentence mean?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d0cee55

add missing patch to the git tree

[jondo]

Replying to jdemeyer:

it is not a frozen source

What does this sentence mean?

Instead of giving each source version a distinctive name, it is (unpleasant) giac convention that the current development snapshot already has the name of the future release (i.e. giac-1.1.2.tar.gz) and will be updated without renaming. You only know that it has become stable when tarballs of the successor version start to appear.

[frederichan]

Replying to jdemeyer:

Replying to frederichan:

it is not a frozen source

What does this sentence mean?

I can see in this repo that the tarball giac-1.1.2.tar.gz is still changing frequently, so the date is important and it is currently not good for checksums that 's why I stayed with 1.1.1 + patches.

[jdemeyer]

Replying to jondo:

Instead of giving each source version a distinctive name, it is (unpleasant) giac convention that the current development snapshot already has the name of the future release (i.e. giac-1.1.2.tar.gz) and will be updated without renaming.

Are you sure? I am asking because ​http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_frozen.tgz points to giac-1.1.2.tar.gz

I would like some clarity about this. If giac-1.1.2 really is the latest version, that's obviously the version you should use.

[parisse]

I froze version 1.1.2 2 days ago, but a few bugs were discovered just after (HP Prime bugs, geogebra regression tests and a bug from pocketcas), therefore I decided to update the tarball and stable binaries yesterday. Now it should really be frozen.

[jdemeyer]

Replying to parisse:

I froze version 1.1.2 2 days ago, but a few bugs were discovered just after (HP Prime bugs, geogebra regression tests and a bug from pocketcas), therefore I decided to update the tarball and stable binaries yesterday.

You should never update released tarballs. If there are bugs, just release 1.1.3 then.

[parisse]

It takes too much time to change version number. I only change the subsubsubrelease version, in debianold/changelog and in config.h for windows and mac binaries. To be more precise, 1.1.2 is 1.1.2-8.

[jdemeyer]

Replying to parisse:

It takes too much time to change version number.

It shouldn't. You really should change your release management procedures to fix this.

Why not add the subsubsubrelease number to the tarball name (giac-1.1.2-8.tar.gz)? Or, you could drop version numbers altogether and use dates (giac-20141009.tar.gz) like some other projects do.

But absolutely: never change a released tarball, no matter how bad/broken it is.

[parisse]

How do you add a subsubsubrelease number or date to the tarball with autotools and make dist?

[jondo]

I would even suggest to use ​Semantic Versioning instead. Then changing the 3rd number ("patch version") would be enough for bugfixes.

[dimpase]

Replying to parisse:

How do you add a subsubsubrelease number or date to the tarball with autotools and make dist?

e.g. put the following in configure.ac and Makefile.am:

REVNUM=`date +%Y%m%d`
AC_SUBST(REVNUM)

then $(REVNUM) can be used in naming the tarball the dist target.

[zimmerma]

is there a way to remove my name from the cc list? There is too much traffic for that ticket.

[parisse]

I just tried REVNUM=date +%Y%m%d AC_SUBST(REVNUM) but it does not work. I get a missing separator if I add it to Makefile.am and if I add it only to configure.in then the archive name is unchanged.

[dimpase]

Replying to parisse:

I just tried REVNUM=date +%Y%m%d AC_SUBST(REVNUM) but it does not work. I get a missing separator if I add it to Makefile.am and if I add it only to configure.in then the archive name is unchanged.

indeed, my bad, you should only add it to configure.am. Did you re-generate all the makefiles etc?

(and certainly you also need to modify the dist target in the toplevel Makefile to reflect the use of REVNUM)

[parisse]

I don't have a configure.am file, only a configure.in, and I think that everything was regenerated after modifying it. I can't modify by hand the toplevel Makefile, it is generated by configure. I'm afraid I don't have time to make it work myself...

[frederichan]

I have asked Bernard to not change the 1.1.2 tar ball anymore, so I will package it after confirmation. ​http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=8&t=1537&p=7522#p7522

[jdemeyer]

Replying to frederichan:

I have asked Bernard to not change the 1.1.2 tar ball anymore, so I will package it after confirmation. ​http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=8&t=1537&p=7522#p7522

Seems like it's already the third time the source was promised to be stable...

@parisse: the fact that "it takes too much time to change version number" is a very poor excuse for such bad release management. You really should learn to never change released versions if you want to be taken seriously. If I were you, I would make it a priority to fix your release management procedure such that this problem doesn't occur anymore in the future.

[parisse]

jdemeyer: not a very constructive comment. I have tried the suggestion proposed by dimpass, unfortunately it does not work. If another suggestion works, I'll integrate it but I don't have time to search for that myself, bug fixing and enhancements is my priority, and that's also true for projects that consider giac *seriously* (geogebra, HP Prime calculator, Pocket CAS to name a few). If you don't like that I keep the same tarball name, it would perhaps be more convenient for sage to work from the geogebra SVN repository of giac: ​https://dev.geogebra.org/trac/browser/trunk/geogebra/common/src/giac

[jdemeyer]

Replying to parisse:

jdemeyer: not a very constructive comment.

I cannot give a constructive comment since I don't understand the problem.

I have tried the suggestion proposed by dimpass, unfortunately it does not work.

I mainly don't understand why you don't simply increase the version number. The second release of 1.1.2 should have been 1.1.3 and the most recent version should have been 1.1.4.

it would perhaps be more convenient for sage to work from the geogebra SVN repository of giac

That would not really be "more convenient" since it doesn't provide ready-made tarballs.

[parisse]

The problem is : it takes me a couple of hours at least to update links/change scripts to recompile all the binaries (win32/64, mac, linux). I don't want to loose that time each time a make a 5 minutes fix in the code. I do that for major reasons (for example new code for computing Groebner basis or have a new version number for French math teacher competitions ...). These steps could perhaps be automated but doing that myself would probably make me crazy. The vast majority of my user basis are end users, they don't care at all about the source tarball name, but they are very happy to get a fast update of the binaries when they report a bug (often 1 or 2 days after). Perhaps a convenient solution for sage would be a wget on my site and then the tarball name would be changed to giac-YYYYMMDD.tar.bz2.

[dimpase]

Replying to parisse:

The problem is : it takes me a couple of hours at least to update links/change scripts to recompile all the binaries (win32/64, mac, linux). I don't want to loose that time each time a make a 5 minutes fix in the code.

I don't understand: all you need to do to update the version number is to change one line in configure.in (and then obviously rerun the whole building process). How does this take a couple of hours of your time, is hard to see.

What exactly do you need changed in your building procedure? And how would making it dependent on e.g. the date make it any faster?

I do that for major reasons (for example new code for computing Groebner basis or have a new version number for French math teacher competitions ...). These steps could perhaps be automated but doing that myself would probably make me crazy. The vast majority of my user basis are end users, they don't care at all about the source tarball name, but they are very happy to get a fast update of the binaries when they report a bug (often 1 or 2 days after).

And how often do they report a bug you already fixed, just because they have no means to see if you did an update of the tarball?

Perhaps a convenient solution for sage would be a wget on my site and then the tarball name would be changed to giac-YYYYMMDD.tar.bz2.

This won't give Sage a way to keep it up to day, as we certainly would have no idea whether a you did a hidden update of the tarball.

[parisse]

Changing the tarball name would not impact too much (I would have to remove old archives from time to time and taking care when saving the tarball to an USB key), but changing the directory name stored inside the tarball has more impact, I need to modify build scripts, move build directories and update links, and sometimes rebuild all the source instead of recompiling a few modified files. Most users reporting bugs do not compile giac themselves, they are using geogebra, the HP Prime calculator and report on respectives forums or Xcas binaries and report on Xcas forum. I don't understand what's the problem on sage side, why not take the latest stable archive from my site when you are doing a compilation? Why is it so important to have a different tarball number on my site each time I make a fix? You can add any stamp you want on your side with the date or sage release number or whatever. That's the way geogebra works, they are just building with the latest SVN revision of giac, and they add their own release number.

[dimpase]

Replying to parisse:

Changing the tarball name would not impact too much (I would have to remove old archives from time to time and taking care when saving the tarball to an USB key), but changing the directory name stored inside the tarball has more impact, I need to modify build scripts, move build directories and update links, and sometimes rebuild all the source instead of recompiling a few modified files. Most users reporting bugs do not compile giac themselves, they are using geogebra, the HP Prime calculator and report on respectives forums or Xcas binaries and report on Xcas forum. I don't understand what's the problem on sage side, why not take the latest stable archive from my site when you are doing a compilation? Why is it so important to have a different tarball number on my site each time I make a fix? You can add any stamp you want on your side with the date or sage release number or whatever. That's the way geogebra works, they are just building with the latest SVN revision of giac, and they add their own release number.

The problem is that we do not want bug reports related to a version we have no good means to track. Indeed, it would look as follows: we get a bug report, on giac version x.y.z. But because x.y.z is not frozen, such a report needs to be tested with "latest" x.y.z. And would would be the means to check that "latest" x.y.z is different from the one we have supplied? None, short of comparing the sources file by file...

I looked at what geogebra does. You have commits into their SVN tree, in the trunk. How do your tarballs relate to what they release, and how to extract what we need from there, it's not clear at all.

Do you have a separate RCS repo somewhere? I don't see any links to it on your giac pages, and geogebra on ​https://dev.geogebra.org/trac/wiki/SourcesForUsedLibraries just points to your homepage, and it has no pointers to the source (why?). While you actually seem to be comitting directly to the geogebra source tree...

[parisse]

I indeed commit directly to geogebra SVN. I therefore see no need to have a separate public repository somewhere else. I don't understand your concern about bug reports. If sage users find a bug in giac code, then it will be treated like bugs detected in ggb or HP or Xcas, i.e. I do my best to fix them in giac. Sage developpers are not really involved here, once the bug has been tagged as a giac bug and I receive an email about the bug (of course if someone in the Sage community want to help me find the bug in my c++ source he is welcome). You just have to take care of compiling the latest stable source to make sure all fixes are in.

[dimpase]

Replying to parisse:

I indeed commit directly to geogebra SVN. I therefore see no need to have a separate public repository somewhere else. I don't understand your concern about bug reports. If sage users find a bug in giac code, then it will be treated like bugs detected in ggb or HP or Xcas, i.e. I do my best to fix them in giac. Sage developpers are not really involved here, once the bug has been tagged as a giac bug and I receive an email about the bug (of course if someone in the Sage community want to help me find the bug in my c++ source he is welcome). You just have to take care of compiling the latest stable source to make sure all fixes are in.

If I look at e.g. ​https://dev.geogebra.org/trac/log/trunk/geogebra/common/src/giac/config.h?rev=36861 I can only conclude that there must be some human decision involved into what goes into a geogebra release, and what doesn't. That is we cannot reliably assume that a commit into ​https://dev.geogebra.org/trac/log/trunk/geogebra/common/src/giac/ means a new giac release. Moreover, we cannot even just use ​https://dev.geogebra.org/, i.e. a geogebra web service, this way, as it violates their licence at ​http://www.geogebra.org/license

[...]
Non-commercial License Terms
[...]
This License incorporates (by reference) additional license terms published by the Free Software Foundation and the Creative Commons Corporation. In the event of any conflict between those additional terms and the terms of this License, the latter shall prevail.

The GeoGebra installers and web services (including the various materials and resources available at ) are licensed to you (on a limited, non-exclusive, personal, non-transferable and royalty-free license) under which you are free to use, copy, distribute, modify and transmit the GeoGebra installers and web services PROVIDED THAT you only do so for non-commercial purposes (without charging a fee to any third party) and PROVIDED THAT you attribute the work to us by (at least) mentioning our name, including an appropriate copyright notice and providing a link to our website located at //www.geogebra.org/

In short, how on Earth does one know what the "latest stable" is?

[parisse]

config.h is a bad example, since it's created by configure, and not part of the tarball. Ok, perhaps you can not rely on ggb SVN for license reasons, but you can still access to the latest giac tarball on my website, what else do you need?

[dimpase]

Replying to parisse:

config.h is a bad example, since it's created by configure, and not part of the tarball. Ok, perhaps you can not rely on ggb SVN for license reasons, but you can still access to the latest giac tarball on my website, what else do you need?

Your tarballs are not stable. We can't tell whether what we ship is the latest, or not. Well, one can run a cron job that will pull the tarball and compare it with what we ship. But, you know, this would go too far, IMHO. You seem to be violating GPL, too: Cf. ​http://www.gnu.org/copyleft/gpl.html

...GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

[frederichan]

I believe that the situation would be less confusing if the current source tarball was not numbered (ex: giac-snapshot.tar.gz) or dated numbered. (Except the ambiguity of the latest name, I can confirm that the older tarball were always trustworthy for checksums.)

Now you distribute binaries in your stable debian repo, (if I do dpkg-buildpackage it creates a giac_1.1.2-8.tar.gz source package) so could't you add it in your stable debian repo when you release a new stable package?

[parisse]

Excellent idea Frederic. I can easily make a copy of the tar.gz generated by the debian package builder into the stable repository. The best location is probably ​http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/

[jdemeyer]

Replying to dimpase:

You seem to be violating GPL, too:

Off topic, but no he isn't. He is changing his own code and that's fine. He can do with his own code what he wants. The point is that I wouldn't be allowed to release a "giac-1.1.2" which is different from the official version without clearly marking it as different.

[jdemeyer]

Replying to parisse:

Why is it so important to have a different tarball number on my site each time I make a fix?

To be clear: I don't find it important that you make a new version every time you make a fix. But those fixes should go into unstable versions. Once you publicly announce a stable tarball, it has to remain unchanged. Fixes can still go into the next unstable non-frozen version.

[dimpase]

Replying to jdemeyer:

Replying to dimpase:

You seem to be violating GPL, too:

Off topic, but no he isn't. He is changing his own code and that's fine. He can do with his own code what he wants. The point is that I wouldn't be allowed to release a "giac-1.1.2" which is different from the official version without clearly marking it as different.

No, this does not make sense: if it were true then the author of a GPLed code changing the source of the released version x.y.z on the fly would cause all the re-distributors of the code in question to be in breach of GPL. I would rather interpret this situation as the violation of GPL by the author, as this can be seen as denial of requests by re-distributors to see the source of x.y.z: instead they are shown something modified!

[jdemeyer]

Replying to dimpase:

if it were true then the author of a GPLed code changing the source of the released version x.y.z on the fly would cause all the re-distributors of the code in question to be in breach of GPL.

I doubt it. The fact that the author changes the source afterwards doesn't matter, the re-distributors still copied the source from the author.

I would rather interpret this situation as the violation of GPL by the author

I don't think that's even possible. The GPL is about copyright and I don't see how an author can violate the copyright of his own works.

[frederichan]

Just to say that the giac_1.1.2-8.tar.gz would be clear but not so easy to handle for a packager because it often means upstreamsource-packageversion and they untar as 1.1.2.

So it would be would be more coherent if the x.y.z tarball was the first one of your x.y.z-w packages and the current source with anothername. (or the last one and announce the packages as prerelease)

[dimpase]

Replying to jdemeyer:

Replying to dimpase:

if it were true then the author of a GPLed code changing the source of the released version x.y.z on the fly would cause all the re-distributors of the code in question to be in breach of GPL.

I doubt it. The fact that the author changes the source afterwards doesn't matter, the re-distributors still copied the source from the author.

re-distributors can just refer to the tarball of the source published by the author, and distribute binaries.

I would rather interpret this situation as the violation of GPL by the author

I don't think that's even possible. The GPL is about copyright and I don't see how an author can violate the copyright of his own works.

GPL is also about providing the source, and the author can violate this rather easily. And the author would violate this part of GPL in this way, for after the change he did to the tarball of x.y.z, without bumping up the version, the sources don't match the binaries.

[parisse]

dimpase, I believe you are wrong, because the author is not bound by the copyright license, unlike other using his work. Anyway, I believe it would be more constructive to focus again on giac integration in sage.

[dimpase]

Replying to parisse:

dimpase, I believe you are wrong, because the author is not bound by the copyright license, unlike other using his work.

GPL is not only a copyright licence. By releasing under GPL, the author has an obligation to release the source code (and moreover in the "preferred form"). You are not doing this, as I clearly explained.

[parisse]

Of course I'm releasing the source code. Since you persist in this attitude, it's plain clear I have lost enough time here. Goodbye.

[jdemeyer]

Replying to dimpase:

the author can violate this rather easily.

Like I said before, no he cannot. The GPL is a license, not a law. The author (more precisely, the copyright holder) is not bound by this license. Other people do have to follow the rules of the license if they use rights provided by that license.

[dimpase]

Replying to jdemeyer:

Replying to dimpase:

the author can violate this rather easily.

Like I said before, no he cannot. The GPL is a license, not a law. The author (more precisely, the copyright holder) is not bound by this license. Other people do have to follow the rules of the license if they use rights provided by that license.

Do you mean to say you can release binaries under GPL and do not provide complete corresponding source? Well, obviously the answer is no...

Anyhow, perhaps Sage can redistribute giac with a notice saying that we don't know the license terms for it.

[jdemeyer]

Replying to dimpase:

Do you mean to say you can release binaries under GPL and do not provide complete corresponding source? Well, obviously the answer is no...

What does "under GPL" even mean for the copyright holder? Nothing, so yes, the copyright holder can release binaries and not provide complete corresponding source.

[jondo]

@dimpase: IANAL, but I do agree with jdemeyer and parisse. Releasing a (totally self-authored) binary under GPL without releasing the source is not illegal. However, it is setting up a trap, because redistribution is illegal without source.

[dimpase]

Replying to jondo:

@dimpase: IANAL, but I do agree with jdemeyer and parisse. Releasing a (totally self-authored) binary under GPL without releasing the source is not illegal. However, it is setting up a trap, because redistribution is illegal without source.

So you think that setting up traps is legal? Well, perhaps it is, but it is not nice.

Other distributions, e.g. archlinux, seem to have enough ​pain with giac already. As long as this is a trap of this sort, I'm against Sage having anything to do with giac.

[frederichan]

My feeling is that for future versions x.y.z being a link to the first stable x.y.z-t would satify every one. no?

what to do with 1.1.2 is another story. But up to now I have only packaged 1.1.1 and it was a trustable source.

[dimpase]

Replying to frederichan:

My feeling is that for future versions x.y.z being a link to the first stable x.y.z-t would satify every one. no?

what to do with 1.1.2 is another story. But up to now I have only packaged 1.1.1 and it was a trustable source.

This would be OK, sure, if there were stable source releases to be used. This however would mean that the feedback from spkg users is not very useful.

[jdemeyer]

Replying to dimpase:

Other distributions, e.g. archlinux, seem to have enough ​pain with giac already. As long as this is a trap of this sort, I'm against Sage having anything to do with giac.

I hope that this ticket in Sage helps to get the giac people to understand that changing sources isn't appreciated. If that gets fixed, I think this Sage package should be upgraded to 1.1.2 (instead of manually adding the patch).

[frederichan]

Hi all, bernard started a x.y.z-t ​http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/ I will have a look at it.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​16aedc1	giac 1.1.2-10 + add spkg-src + add patch for pari ifactor under osx
​137487f	giacpy 0.4.5: Fix in __call__, try, sig_on and giac errors such as pari lock messages.
​12e9309	improve spkg-src

[frederichan]

Now working with a spkg-src to make the top dir name easier to handle by the installer and to remove the huge french html doc which was not released under GPL terms. ( Freely resdistribuable for non commercial purposes)

Cf the ticket description link to download giac-1.1.2.10.tar.gz.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d78b1f2

add the patch to allow par factor in mac os ifactor. Cf README.txt

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d6e7099

adjust spkg-src and rebuilt pkg.

[jondo]

Just my 2 cents: ​public/giac_spkg still has Source file (giac-x.y.z.tar.gz) in: http://www-fourier.ujf-grenoble.fr/~parisse/giac/ I think this should be updated.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ed40da7

update upstream source link in SPKG.txt

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​7de31ab

update SPKG.txt to announce that the french html doc was removed.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​e8f1042

update giac to 1.1.3-15

[jondo]

Is there still anything missing (besides giac_1.1.4-7.tar.gz already being available), or is this now ready for the reviewers?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​1e70957

update to upstream 1.1.4-7. And fix the patches of the check suite accordingly.

[frederichan]

New commits:

​1e70957

update to upstream 1.1.4-7. And fix the patches of the check suite accordingly.

---

New commits:

​1e70957

update to upstream 1.1.4-7. And fix the patches of the check suite accordingly.

[jdemeyer]

One small remark for now: instead of splitting up the "nofltk" patch into many files, can you just make it one patch file? That would be much clearer.

[jdemeyer]

If you adapt the patch like I said, then I will continue my review.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​105298d	update to upstream 1.1.4-10
​add5ebc	update checksum
​fa05b47	rewrite the nofltk patches. Put graphic options in several source check files to obtain the same

[frederichan]

Thank your care. I have got a better idea for the nofltk patches than befor. I found and put all the graphics/color options in the sources check files so that the output should be similar when compiling with or without fltk. It should be easier when upgrading to new giac versions and gives much smaller and readable patches.

[jdemeyer]

The giacpy testsuite doesn't compile:

Successfully installed giacpy-0.4.5
Running the test suite for giacpy-0.4.5...
too many failed tests, not using stored timings
Running doctests with ID 2015-03-02-19-28-38-6f231793.
Git branch: t/12375/public/giac_spkg
Doctesting 1 file.
sage -t giacpy.pyx
Compiling ./giacpy.pyx...
    RuntimeError in doctesting framework
**********************************************************************
Traceback (most recent call last):
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 2128, in __call__
    doctests, extras = self.source.create_doctests(sage_namespace)
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/doctest/sources.py", line 661, in create_doctests
    load(filename, namespace) # errors raised here will be caught in DocTestTask
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/repl/load.py", line 294, in load
    exec(load_cython(fpath), globals)
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/repl/load.py", line 65, in load_cython
    mod, dir = cython(name, compile_message=True, use_cache=True)
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/misc/cython.py", line 493, in cython
    raise RuntimeError("Error converting {} to C:\n{}\n{}".format(filename, log, err))
RuntimeError: Error converting ./giacpy.pyx to C:


Error compiling Cython file:
------------------------------------------------------------
...


########################################################
# A global context pointer. One by giac session.
########################################################
cdef context * context_ptr=new context()
    ^
------------------------------------------------------------

_usr_local_src_sage_git_local_var_tmp_sage_build_giacpy_0_4_5_src_giacpy_pyx_0.pyx:211:5: 'context' is not a type identifier
[...]

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f71bc55	Merge git://trac.sagemath.org/sage into t/12375/public/giac_spkg
​bb9cbfe	add --force-lib in spkg-check to not try to compile giacpy.pyx during tests

[frederichan]

Indeed, we want to test the newly built giacpy.so using the docstrings of giacpy.pyx and don't want sage -t to try to (baddly) compile it. So I have put in the testsuite sage -t --force-lib giacpy.pyx

[frederichan]

small built failure with pari 2.8. waiting a little for upstream modifications. ​http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1634

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​c66d104	update SPKG.txt to announce that the french html doc was removed.
​9fe3d19	update giac to 1.1.3-15
​cee1552	update to upstream 1.1.4-7. And fix the patches of the check suite accordingly.
​ff9aefd	update to upstream 1.1.4-10
​7585705	update checksum
​75d15ac	rewrite the nofltk patches. Put graphic options in several source check files to obtain the same
​71c346c	add --force-lib in spkg-check to not try to compile giacpy.pyx during tests
​245bc62	update giac to 1.2.0-13 and patch the check suite for pari 2.8
​d03267e	update to 0.4.6. add loadgiacgen + remove PY_TYPE_CHECK
​3fb1480	Merge branch 'public/giac_spkg' of git://trac.sagemath.org/sage into t/12375/public/giac_spkg

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​b64564a

improve the pari check patch to be less version dependent

[frederichan]

So I have updated to giac 1.2.0-13, and giacpy 0.4.6.

[jdemeyer]

OK, let's try again to review this.

In any case, it needs work because all packages need a "type" file now (look at build/pkgs/arb/type for example).

[jdemeyer]

The changes look good to me, so if it actually works, it's good to go.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8b1049f

add type files. (optional)

[frederichan]

Replying to jdemeyer:

OK, let's try again to review this.

Thank you!

I realize that on the computers where I tested my git built there is a ccobject.h in local/include/csage but on a another one it is not there and the built of giacpy fails with this header not found because giacpy cimports Integer (and not ccobject.h directly) Do you have any idea of what I should do? Thanks

[frederichan]

I have tested to put an: export CFLAGS+="-I$SAGE_SRC/sage/ext" in giacpy's spkg-install, it solves the problem. Do you recommand something else?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8f7db49

adapts CFLAGS in spkg-install because of ccobject.h not found due to cimport Integer

[jdemeyer]

I think that changing CFLAGS is not the best solution. I think you need to change the include directories in setup.py, such that Cython knowns about them too.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​bf6509a	Revert "adapts CFLAGS in spkg-install because of ccobject.h not found due to cimport Integer"
​2e5cd0e	update to giacpy-sage 0.4.7 (add an include path in setup.py)

[frederichan]

I don't have problems when building from master, but when building from yesterday develop+trac18666 I have the following error. (I am doing in giacpy.pyx: include 'sage/ext/interrupt.pxi')

gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) 
****************************************************
Deleting /home/fred/dev/sage/local/lib/python/site-packages/giacpy*
running install
running build
running build_ext
cythoning giacpy.pyx to giacpy.cpp
building 'giacpy' extension
creating build
creating build/temp.linux-x86_64-2.7
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/home/fred/dev/sage/local/include -I/home/fred/dev/sage/src -I/home/fred/dev/sage/src/sage/ext -I/home/fred/dev/sage/local/include/csage -I/home/fred/dev/sage/local/include/python2.7 -c giacpy.cpp -o build/temp.linux-x86_64-2.7/giacpy.o
In file included from /home/fred/dev/sage/local/include/giac/poly.h:25:0,
                 from /home/fred/dev/sage/local/include/giac/giac.h:5,
                 from giacpy.cpp:256:
/home/fred/dev/sage/local/include/giac/index.h:33:0: warning: ignoring #pragma anon_unions  [-Wunknown-pragmas]
 #pragma anon_unions
 ^
giacpy.cpp:2359:0: warning: "_signals" redefined
 #define _signals (*__pyx_vp_4sage_3ext_9interrupt_9interrupt__signals)
 ^
In file included from /home/fred/dev/sage/src/sage/ext/interrupt/pxi.h:7:0,
                 from giacpy.cpp:263:
/home/fred/dev/sage/src/build/cythonized/sage/ext/interrupt/interrupt_api.h:16:0: note: this is the location of the previous definition
 #define _signals (*__pyx_api_vp_4sage_3ext_9interrupt_9interrupt__signals)
 ^
giacpy.cpp: In function 'int __pyx_import_star_set(PyObject*, PyObject*, char*)':
giacpy.cpp:134047:55: error: '__pyx_convert__from_py_sage_signals_t' was not declared in this scope
     _signals = __pyx_convert__from_py_sage_signals_t(o); if (PyErr_Occurred()) {__pyx_filename = __pyx_f[5]; __pyx_lineno = 45; __pyx_clineno = __LINE__; goto __pyx_L2_error;};

NB:at line 134047 the giacpy.cpp have the following code that is not in the old one:

  else if (__Pyx_StrEq(name, "_signals")) {
    _signals = __pyx_convert__from_py_sage_signals_t(o); if (PyErr_Occurred()) {__pyx_filename = __pyx_f[5]; __pyx_lineno = 45; __pyx_clineno = __LINE__; goto __pyx_L2_error;};
  }

[jdemeyer]

You might want to wait for #18494, which should make it easier to install external packages using the Sage library.

[jdemeyer]

See #18514 for a package with similar problems. The same trick should work here.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​31a89c5

test of update setup.py to use sage 6.8 include path

[frederichan]

So I have updated setup.py to giacpy-0.4.7b.tar.gz in such a way that it builts on sage 6.7. In particular there is this 'csage' in setup.py but I don't see libcsage.so in my 6.8rc3.

[jdemeyer]

At least part of the problem is this Cython bug: ​http://trac.cython.org/ticket/851

[jdemeyer]

Can you try explicit imports instead of import * and see if that helps?

[frederichan]

Thank you! it improves things. I will clean and test more.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​c7f6087

update giacpy to 0.4.8 (cleanup code)

[frederichan]

Many thanks to all the participants.