Opened 10 years ago

Closed 6 years ago

# Create a giac package

Reported by: Owned by: frederichan tbd minor sage-6.8 packages: optional giac Frederic Han Dima Pasechnik, Jeroen Demeyer N/A c7f6087 #18494

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

Sage packages:

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).
• 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).
• Some computations (determinant, simplifications...) with many variables. Ex

### comment:1 Changed 10 years ago by frederichan

• Description modified (diff)

### comment:2 Changed 10 years ago by frederichan

• Type changed from PLEASE CHANGE to enhancement

### comment:3 Changed 10 years ago by frederichan

• Status changed from new to needs_review

### Changed 10 years ago by frederichan

a copy of the SPKG.txt file included.

### comment:4 Changed 10 years ago by frederichan

• Description modified (diff)

-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.

### comment:5 Changed 10 years ago by frederichan

• Description modified (diff)

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.

### comment:7 Changed 9 years ago by frederichan

• Authors set to Han Frederic

### comment:8 Changed 9 years ago by frederichan

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

### comment:9 Changed 9 years ago by frederichan

• Description modified (diff)

upgrade the spkg to the current version of giac: 1.0.0

### comment:11 Changed 8 years ago by jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

### comment:12 Changed 8 years ago by frederichan

Update to version 1.1 of giac.

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/)

### comment:13 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:14 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:15 follow-up: ↓ 16 Changed 7 years ago by jondo

Would this make giac available in the provided Sage VMs?

### comment:16 in reply to: ↑ 15 Changed 7 years ago by frederichan

Would this make giac available in the provided Sage VMs?

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

Last edited 7 years ago by frederichan (previous) (diff)

### comment:17 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:18 Changed 7 years ago by jondo

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

### comment:19 follow-up: ↓ 20 Changed 7 years ago by dimpase

• Status changed from needs_review to needs_work

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.

Last edited 7 years ago by dimpase (previous) (diff)

### Changed 7 years ago by dimpase

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

### comment:20 in reply to: ↑ 19 Changed 7 years ago by frederichan

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

### comment:21 Changed 7 years ago by 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.

### comment:22 Changed 7 years ago by frederichan

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

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

### comment:23 Changed 7 years ago by zimmerma

• Cc zimmerma removed

### comment:24 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:25 follow-up: ↓ 26 Changed 7 years ago by 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))]


### comment:26 in reply to: ↑ 25 Changed 7 years ago by dimpase

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.

### comment:27 follow-up: ↓ 28 Changed 7 years ago by 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?

### comment:28 in reply to: ↑ 27 Changed 7 years ago by dimpase

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?

### comment:29 follow-up: ↓ 30 Changed 7 years ago by 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.

### comment:30 in reply to: ↑ 29 Changed 7 years ago by dimpase

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

### comment:31 follow-up: ↓ 33 Changed 7 years ago by frederichan

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

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

I have put the spkg scripts there:

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

and the spkg scripts there:

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.

### comment:32 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:33 in reply to: ↑ 31 Changed 7 years ago by dimpase

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

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

I have put the spkg scripts there:

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

and the spkg scripts there:

is it the correct way to distribute new spkg?

Did you look at

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...

Last edited 7 years ago by dimpase (previous) (diff)

### comment:34 Changed 7 years ago by frederichan

• Branch set to u/HanFrederic/submit_a_giac__spkg

### comment:35 Changed 7 years ago by frederichan

• Branch u/HanFrederic/submit_a_giac__spkg deleted

### comment:36 Changed 7 years ago by frederichan

• Branch set to public/giac_spkg

u/Han Frederic/submit_a_giacspkg

Last edited 7 years ago by frederichan (previous) (diff)

### comment:37 Changed 7 years ago by 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
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



### comment:38 Changed 7 years ago by 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.

### comment:39 Changed 7 years ago by 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. ### comment:40 Changed 7 years ago by 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... ### comment:41 Changed 7 years ago by dimpase The RSA/ECDSA thing was due to me having stored the RSA key of the host previously. Nothing weird here... ### comment:42 Changed 7 years ago by git • Commit set to 9562050fcc8774cbfeeaa88479cd8eb5733a45a7 Branch pushed to git repo; I updated commit sha1. New commits:  ​9562050 add giac and giacpy pkg scripts ### comment:43 Changed 7 years ago by 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" Last edited 7 years ago by dimpase (previous) (diff) ### comment:44 Changed 7 years ago by 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. ### comment:45 Changed 7 years ago by vbraun_spam • Milestone changed from sage-6.3 to sage-6.4 ### comment:46 follow-ups: ↓ 47 ↓ 48 Changed 7 years ago by 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? ### comment:47 in reply to: ↑ 46 Changed 7 years ago by 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? 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 ? ### comment:48 in reply to: ↑ 46 Changed 7 years ago by 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 ### comment:49 Changed 7 years ago by jdemeyer • Description modified (diff) • Summary changed from submit a giac spkg to Create a giac package ### comment:50 Changed 7 years ago by 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? ### comment:51 Changed 7 years ago by jdemeyer Please add a link to the correct giac tarball in the ticket description, such that I can at least try it. ### comment:52 Changed 7 years ago by 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. ### comment:53 Changed 7 years ago by frederichan • Description modified (diff) ### comment:54 Changed 7 years ago by frederichan Yes it initializes PARI library, so if there are too many conflicts I will disable pari in the giac spkg. ### comment:55 Changed 7 years ago by 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. ### comment:56 Changed 7 years ago by 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  ### comment:57 Changed 7 years ago by frederichan • Description modified (diff) ### comment:58 Changed 7 years ago by git • Commit changed from 9562050fcc8774cbfeeaa88479cd8eb5733a45a7 to ee6258dd4b92e2ec0c4fb5ad24422564344cbe3d 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. ### comment:59 Changed 7 years ago by 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. ### comment:60 Changed 7 years ago by 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  ### comment:61 Changed 7 years ago by git • Commit changed from ee6258dd4b92e2ec0c4fb5ad24422564344cbe3d to d1b5cfdb0d0c3354462ffcef95183d41763ba60f Branch pushed to git repo; I updated commit sha1. New commits:  ​d1b5cfd clean commented code, unapplied patches and fuz in patch ### comment:62 Changed 7 years ago by frederichan • Description modified (diff) ### comment:63 Changed 7 years ago by git • Commit changed from d1b5cfdb0d0c3354462ffcef95183d41763ba60f to 12dff8c3f5596dba049f9bde9ec23482979a94b3 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: ### comment:64 Changed 7 years ago by frederichan • Description modified (diff) • Status changed from needs_work to needs_review ### comment:65 Changed 7 years ago by dimpase • Reviewers set to Dima Pasechnik, Jeroen Demeyer Looks good to me. Jeroen, how does it look for you? ### comment:66 Changed 7 years ago by jdemeyer • Status changed from needs_review to needs_work 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] """  ### comment:67 Changed 7 years ago by 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

### comment:91 Changed 7 years ago by zimmerma

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

### comment:92 follow-up: ↓ 93 Changed 7 years ago by 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.

### comment:93 in reply to: ↑ 92 Changed 7 years ago by dimpase

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)

Last edited 7 years ago by dimpase (previous) (diff)

### comment:94 Changed 7 years ago by 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...

### comment:95 follow-up: ↓ 96 Changed 7 years ago by 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

Last edited 7 years ago by frederichan (previous) (diff)

### comment:96 in reply to: ↑ 95 Changed 7 years ago by jdemeyer

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.

### comment:97 follow-up: ↓ 98 Changed 7 years ago by 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

### comment:98 in reply to: ↑ 97 Changed 7 years ago by jdemeyer

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.

### comment:99 follow-up: ↓ 100 Changed 7 years ago by 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.

### comment:100 in reply to: ↑ 99 Changed 7 years ago by dimpase

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.

### comment:101 follow-ups: ↓ 102 ↓ 110 Changed 7 years ago by 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.

### comment:102 in reply to: ↑ 101 Changed 7 years ago by dimpase

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...

### comment:103 follow-up: ↓ 104 Changed 7 years ago by 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.

### comment:104 in reply to: ↑ 103 Changed 7 years ago by dimpase

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

[...]
[...]
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?

### comment:105 follow-up: ↓ 106 Changed 7 years ago by 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?

### comment:106 in reply to: ↑ 105 ; follow-up: ↓ 109 Changed 7 years ago by dimpase

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.


### comment:107 Changed 7 years ago by 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?

### comment:108 Changed 7 years ago by 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/

### comment:109 in reply to: ↑ 106 ; follow-up: ↓ 111 Changed 7 years ago by jdemeyer

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.

### comment:110 in reply to: ↑ 101 Changed 7 years ago by jdemeyer

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.

### comment:111 in reply to: ↑ 109 ; follow-up: ↓ 112 Changed 7 years ago by 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!

### comment:112 in reply to: ↑ 111 ; follow-up: ↓ 114 Changed 7 years ago by jdemeyer

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.

### comment:113 Changed 7 years ago by 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)

### comment:114 in reply to: ↑ 112 ; follow-up: ↓ 118 Changed 7 years ago by 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.

### comment:115 follow-up: ↓ 116 Changed 7 years ago by 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.

Last edited 7 years ago by parisse (previous) (diff)

### comment:116 in reply to: ↑ 115 Changed 7 years ago by dimpase

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.

### comment:117 Changed 7 years ago by 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.

### comment:118 in reply to: ↑ 114 ; follow-up: ↓ 119 Changed 7 years ago by jdemeyer

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.

### comment:119 in reply to: ↑ 118 ; follow-up: ↓ 120 Changed 7 years ago by 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.

### comment:120 in reply to: ↑ 119 Changed 7 years ago by jdemeyer

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.

### comment:121 follow-up: ↓ 122 Changed 7 years ago by 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.

### comment:122 in reply to: ↑ 121 ; follow-up: ↓ 125 Changed 7 years ago by dimpase

@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.

### comment:123 follow-up: ↓ 124 Changed 7 years ago by frederichan

• Status changed from needs_review to needs_work

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.

### comment:124 in reply to: ↑ 123 Changed 7 years ago by dimpase

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.

Last edited 7 years ago by dimpase (previous) (diff)

### comment:125 in reply to: ↑ 122 Changed 7 years ago by jdemeyer

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

### comment:126 Changed 7 years ago by 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.

### comment:127 Changed 7 years ago by git

• Commit changed from d0cee55ac0759159ff985e2f3ab645310a174aba to 12e93092b6fa4ff9b93e3cb7e74f56196d7b499b

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

### comment:128 Changed 7 years ago by frederichan

• Description modified (diff)

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)

### comment:129 Changed 7 years ago by git

• Commit changed from 12e93092b6fa4ff9b93e3cb7e74f56196d7b499b to d78b1f26d8929e947e14b0469b016d8dfc3326e5

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

### comment:130 Changed 7 years ago by git

• Commit changed from d78b1f26d8929e947e14b0469b016d8dfc3326e5 to d6e7099f8c1da13157b1f3e8aab6223bdf8bc1ca

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

 ​d6e7099 adjust spkg-src and rebuilt pkg.

### comment:131 Changed 7 years ago by frederichan

• Status changed from needs_work to needs_review

### comment:132 Changed 7 years ago by 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.

### comment:133 Changed 7 years ago by git

• Commit changed from d6e7099f8c1da13157b1f3e8aab6223bdf8bc1ca to ed40da723eaa82d05a45dac32564de879bac9de8

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

 ​ed40da7 update upstream source link in SPKG.txt

### comment:134 Changed 7 years ago by git

• Commit changed from ed40da723eaa82d05a45dac32564de879bac9de8 to 7de31abb1ca2c4689432c9fbb62efb158c309c47

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

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

### comment:135 Changed 7 years ago by git

• Commit changed from 7de31abb1ca2c4689432c9fbb62efb158c309c47 to e8f10420527816299e7373cf1f861646727f303a

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

 ​e8f1042 update giac to 1.1.3-15

### comment:136 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:137 Changed 7 years ago by 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?

### comment:138 Changed 7 years ago by git

• Commit changed from e8f10420527816299e7373cf1f861646727f303a to 1e70957cd546333a2be69d7ec86d321218112c91

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.

### comment:139 Changed 7 years ago by frederichan

• Description modified (diff)

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.

### comment:140 Changed 7 years ago by jdemeyer

• Status changed from needs_review to needs_work

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.

### comment:141 Changed 7 years ago by jdemeyer

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

### comment:142 Changed 7 years ago by git

• Commit changed from 1e70957cd546333a2be69d7ec86d321218112c91 to fa05b47f7622dc3ee139ebfb7cf4daf679aeb776

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

### comment:143 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:144 Changed 7 years ago by frederichan

• Status changed from needs_work to needs_review

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.

### comment:145 Changed 7 years ago by jdemeyer

• Description modified (diff)

### comment:146 Changed 7 years ago by jdemeyer

• Status changed from needs_review to needs_work

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
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
[...]


### comment:147 Changed 7 years ago by git

• Commit changed from fa05b47f7622dc3ee139ebfb7cf4daf679aeb776 to bb9cbfe528796c3f209da30fe67da30dc2c6cfb2

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

### comment:148 Changed 7 years ago by frederichan

• Status changed from needs_work to needs_review

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

### comment:149 Changed 7 years ago by frederichan

• Status changed from needs_review to needs_work

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

### comment:150 Changed 7 years ago by git

• Commit changed from bb9cbfe528796c3f209da30fe67da30dc2c6cfb2 to 3fb1480c0be6c3cb1749f7a8959fd21090aca25e

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

### comment:151 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:152 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:153 Changed 7 years ago by git

• Commit changed from 3fb1480c0be6c3cb1749f7a8959fd21090aca25e to b64564a9d9db35532abef430527c6571d9f33f4b

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

 ​b64564a improve the pari check patch to be less version dependent

### comment:154 Changed 7 years ago by frederichan

• Status changed from needs_work to needs_review

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

### comment:155 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:156 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:157 follow-up: ↓ 160 Changed 7 years ago by jdemeyer

• Milestone changed from sage-6.4 to sage-6.8
• Status changed from needs_review to needs_work

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

### comment:158 Changed 7 years ago by jdemeyer

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

### comment:159 Changed 7 years ago by git

• Commit changed from b64564a9d9db35532abef430527c6571d9f33f4b to 8b1049f30bc0bcb542d29e336ce64402def0bc52

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

 ​8b1049f add type files. (optional)

### comment:160 in reply to: ↑ 157 Changed 7 years ago by frederichan

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

### comment:161 Changed 7 years ago by 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?

### comment:162 Changed 7 years ago by git

• Commit changed from 8b1049f30bc0bcb542d29e336ce64402def0bc52 to 8f7db49a3df0ffea99692a18fad5bf9d300294a7

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

### comment:163 Changed 7 years ago by 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.

### comment:164 Changed 7 years ago by git

• Commit changed from 8f7db49a3df0ffea99692a18fad5bf9d300294a7 to 2e5cd0ee3dc0df98cbb1d1f5a1a3dc9cc0d1a62a

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)

### comment:165 Changed 7 years ago by frederichan

• Description modified (diff)

### comment:166 Changed 7 years ago by 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;};
}


### comment:167 Changed 7 years ago by jdemeyer

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

### comment:168 Changed 7 years ago by jdemeyer

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

### comment:169 Changed 6 years ago by jdemeyer

• Dependencies set to #18494

### comment:170 Changed 6 years ago by jdemeyer

• Description modified (diff)

### comment:171 Changed 6 years ago by frederichan

• Description modified (diff)

### comment:172 Changed 6 years ago by git

• Commit changed from 2e5cd0ee3dc0df98cbb1d1f5a1a3dc9cc0d1a62a to 31a89c52f35b4bf385de9d6fc98be54a9f972616

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

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

### comment:173 Changed 6 years ago by 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.

### comment:174 Changed 6 years ago by jdemeyer

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

### comment:175 Changed 6 years ago by jdemeyer

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

### comment:176 Changed 6 years ago by frederichan

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

### comment:177 Changed 6 years ago by git

• Commit changed from 31a89c52f35b4bf385de9d6fc98be54a9f972616 to c7f6087b946934ed18f25734a635e805d5b064a3

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

 ​c7f6087 update giacpy to 0.4.8 (cleanup code)

### comment:178 Changed 6 years ago by frederichan

• Description modified (diff)

### comment:179 Changed 6 years ago by frederichan

• Status changed from needs_work to needs_review

### comment:180 Changed 6 years ago by jdemeyer

• Status changed from needs_review to positive_review

### comment:181 Changed 6 years ago by vbraun

• Branch changed from public/giac_spkg to c7f6087b946934ed18f25734a635e805d5b064a3
• Resolution set to fixed
• Status changed from positive_review to closed

### comment:182 Changed 6 years ago by frederichan

• Commit c7f6087b946934ed18f25734a635e805d5b064a3 deleted

Many thanks to all the participants.

### comment:183 Changed 6 years ago by jdemeyer

• Authors changed from Han Frederic to Frederic Han

### comment:184 Changed 6 years ago by jondo

• Cc jondo removed
Note: See TracTickets for help on using tickets.