#12375 closed enhancement (fixed)
Create a giac package
Reported by:  frederichan  Owned by:  tbd 

Priority:  minor  Milestone:  sage6.8 
Component:  packages: optional  Keywords:  giac 
Cc:  Merged in:  
Authors:  Frederic Han  Reviewers:  Dima Pasechnik, Jeroen Demeyer 
Report Upstream:  N/A  Work issues:  
Branch:  c7f6087 (Commits, GitHub, GitLab)  Commit:  
Dependencies:  #18494  Stopgaps: 
Description (last modified by )
The build of the GUI (xcas
) has been disabled in the spkginstall
to minimize the dependencies.
Sage packages:
 http://webusers.imjprg.fr/~frederic.han/xcas/sage/giac1.2.0.13.tar.gz
 http://www.imjprg.fr/~frederic.han/xcas/giacpy/sage/giacpy0.4.8.tar.gz
The Sage giac
package was built with spkgsrc
from the original giac 1.2.013 source:
http://wwwfourier.ujfgrenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.2.013.tar.gz
giacpysage git repository: https://gitlab.math.univparisdiderot.fr/han/giacpysage
worksheets and pdf examples https://www.imjprg.fr/~frederic.han/xcas/giacpy/
Some interresting applications
 Grobner basis (revlex) over QQ and Zp (+ some multithreadings).
https://www.imjprg.fr/~frederic.han/xcas/giacpy/grobnerlibgiac.sws or https://www.imjprg.fr/~frederic.han/xcas/giacpy/grobnerlibgiac.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.imjprg.fr/~frederic.han/xcas/giacpy/index.html#cyclic9
 Some computations (determinant, simplifications...) with many variables. Ex
https://www.imjprg.fr/~frederic.han/xcas/giacpy/giacpycubics.sws or https://www.imjprg.fr/~frederic.han/xcas/giacpy/giacpycubics.pdf
 Symbolic calculus. Ex solving some inequalities, but also some primitive may be more lucky (cf the constant term in https://www.imjprg.fr/~frederic.han/xcas/giacpy/plotlibgiac.pdf)
Attachments (2)
Change History (186)
comment:1 Changed 9 years ago by
 Description modified (diff)
comment:2 Changed 9 years ago by
 Type changed from PLEASE CHANGE to enhancement
comment:3 Changed 9 years ago by
 Status changed from new to needs_review
Changed 9 years ago by
comment:4 Changed 9 years ago by
 Description modified (diff)
update to giac 0.9.6
The CFLAGS and CXXFLAGS settings in spkginstall had been removed because it was not necessary to force their values.
comment:5 Changed 9 years ago by
 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:6 Changed 9 years ago by
Please fill in your real name as Author.
comment:7 Changed 9 years ago by
comment:8 Changed 9 years ago by
Updated to giac 0.9.8 (current stable) http://people.math.jussieu.fr/~han/xcas/giac0.9.8.spkg
comment:9 Changed 8 years ago by
 Description modified (diff)
upgrade the spkg to the current version of giac: 1.0.0
comment:10 Changed 8 years ago by
 Cc zimmerma added
comment:11 Changed 8 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:12 Changed 8 years ago by
Update to version 1.1 of giac.
http://www.math.jussieu.fr/~han/xcas/sage/giac1.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/)
comment:13 Changed 7 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:14 Changed 7 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:15 followup: ↓ 16 Changed 7 years ago by
 Cc jondo added
Would this make giac available in the provided Sage VMs?
(Context: Solving rational inequality should give simplified result)
comment:16 in reply to: ↑ 15 Changed 7 years ago by
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/giac1.1.1.spkg
Best regards
comment:17 Changed 7 years ago by
 Description modified (diff)
comment:18 Changed 7 years ago by
In the mentioned sagedevel thread Dima Pasechnik asked: "Was there a vote carried out for inclusion of such an spkg?"
comment:19 followup: ↓ 20 Changed 7 years ago by
 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.
comment:20 in reply to: ↑ 19 Changed 7 years ago by
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.ujfgrenoble.fr/XCAS/viewtopic.php?f=4&t=1518
Best regards, Frederic
comment:21 Changed 7 years ago by
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
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
comment:23 Changed 7 years ago by
 Cc zimmerma removed
comment:24 Changed 7 years ago by
 Description modified (diff)
comment:25 followup: ↓ 26 Changed 7 years ago by
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.imjprg.fr/~frederic.han/xcas/sage/giac1.1.2.spkg
I have also done an spkg of the cython interface and called it giacpy. https://www.imjprg.fr/~frederic.han/xcas/sage/giacpy0.4.spkg
sample test:
from giacpy import * libgiac.solve(xx*exp(x/1001)>0, x)
should give:
list[((x>0) and (x<100))]
comment:26 in reply to: ↑ 25 Changed 7 years ago by
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.
comment:27 followup: ↓ 28 Changed 7 years ago by
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
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.imjprg.fr/~frederic.han/xcas/sage/giac1.1.2.spkg is down. Could you host it somewhere else?
comment:29 followup: ↓ 30 Changed 7 years ago by
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
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 giac1.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 followup: ↓ 33 Changed 7 years ago by
hello, so I have worked (and generated checksums) with the following upstream source
http://wwwfourier.ujfgrenoble.fr/~parisse/giac/giac1.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.imjprg.fr/~frederic.han/xcas/sage/giac.tar.bz2
For the cython interface giacpy, I have put the upstream source file:
https://www.imjprg.fr/~frederic.han/xcas/giacpy/sage/giacpy0.4.tar.gz
and the spkg scripts there:
https://www.imjprg.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.
comment:32 Changed 7 years ago by
 Description modified (diff)
comment:33 in reply to: ↑ 31 Changed 7 years ago by
Replying to Han Frederic:
hello, so I have worked (and generated checksums) with the following upstream source
http://wwwfourier.ujfgrenoble.fr/~parisse/giac/giac1.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.imjprg.fr/~frederic.han/xcas/sage/giac.tar.bz2
For the cython interface giacpy, I have put the upstream source file:
https://www.imjprg.fr/~frederic.han/xcas/giacpy/sage/giacpy0.4.tar.gz
and the spkg scripts there:
https://www.imjprg.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...
comment:34 Changed 7 years ago by
 Branch set to u/HanFrederic/submit_a_giac__spkg
comment:35 Changed 7 years ago by
 Branch u/HanFrederic/submit_a_giac__spkg deleted
comment:37 Changed 7 years ago by
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/sage6.2/local/bin/gittrac", line 18, in <module> cmdline.launch() File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/cmdline.py", line 132, in launch app.push(ticket_number) File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/app.py", line 147, in push self.repo.push(remote) File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/git_repository.py", line 150, in push self.git.echo.push('trac', 'HEAD:'+remote_branch) File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/git_interface.py", line 355, in meth return self.execute(git_cmd, *args, **kwds) File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/git_interface.py", line 98, in execute popen_stderr=subprocess.PIPE) File "/usr/local/sage6.2/local/lib/python2.7/sitepackages/git_trac/git_interface.py", line 262, in _run raise GitError(result) git_trac.git_error.GitError: git returned with nonzero 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
Do you use git trac extension (https://github.com/sagemath/gittraccommand) ?
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
Yes I have used gittrac 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)$ gittrac 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/gittraccommand.git (fetch) origin https://github.com/sagemath/gittraccommand.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)$ sshkeygen l Enter file in which the key is (/home/fred/.ssh/id_rsa): /home/fred/.ssh/id_rsatrac 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_rsatrac git@trac.sagemath.org info OpenSSH_5.9p1 Debian5ubuntu1.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_rsatrac type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA2048 debug1: identity file /home/fred/.ssh/id_rsatraccert type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian5ubuntu1.3 debug1: match: OpenSSH_5.9p1 Debian5ubuntu1.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH2.0OpenSSH_5.9p1 Debian5ubuntu1.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server>client aes128ctr hmacmd5 none debug1: kex: client>server aes128ctr hmacmd5 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_rsatrac 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
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
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
 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
to get giac to compile on my Debian system, I had to
aptget 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"
comment:44 Changed 7 years ago by
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/sage6.3.beta7/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 480, in _run self.execute(example, compiled, test.globs) File "/home/dima/sage/sage6.3.beta7/local/lib/python2.7/sitepackages/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/sage6.3.beta7/local/lib/python2.7/sitepackages/sage/interfaces/giac.py", line 322, in _keyboard_interrupt raise RuntimeError("Ctrlc pressed while running %s"%self) RuntimeError: Ctrlc 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^23*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
 Milestone changed from sage6.3 to sage6.4
comment:46 followups: ↓ 47 ↓ 48 Changed 7 years ago by
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 controlc 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
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 tutuhitting a controlc 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#interruptandsignalhandling
It could be that things got changed there since 5.11 (I don't know for sure; ask on sagedevelop if problems persist here). Do you do sign_on
and sign_off
?
comment:48 in reply to: ↑ 46 Changed 7 years ago by
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#usingsigonandsigoff
comment:49 Changed 7 years ago by
 Description modified (diff)
 Summary changed from submit a giac spkg to Create a giac package
comment:50 Changed 7 years ago by
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 controlc).
sage: import giacpy // Giac share rootdirectory:/usr/local/sage6.2/local/share/giac/ // Using keyword file /usr/local/sage6.2/local/share/giac/doc/fr/keywords // Giac share rootdirectory:/usr/local/sage6.2/local/share/giac/ Help file /usr/local/sage6.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
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
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
 Description modified (diff)
comment:54 Changed 7 years ago by
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
I notice your package does
aclocal autoconf automake addmissing 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
My installation of your giac
package fails with
make allrecursive make[1]: Entering directory `/usr/local/src/sageconfig/local/var/tmp/sage/build/giac1.1.1/src' Making all in src make[2]: Entering directory `/usr/local/src/sageconfig/local/var/tmp/sage/build/giac1.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 fnostrictaliasing 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/sageconfig/local/var/tmp/sage/build/giac1.1.1/src/src' make[1]: *** [allrecursive] Error 1 make[1]: Leaving directory `/usr/local/src/sageconfig/local/var/tmp/sage/build/giac1.1.1/src' make: *** [all] Error 2
comment:57 Changed 7 years ago by
 Description modified (diff)
comment:58 Changed 7 years ago by
 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 spkginstall.

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
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
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/TP00sol.cas.out1 patching file check/TP02sol.cas.out1 patching file check/TP09sol.cas.out1 patching file check/TP19sol.cas.out1 patching file check/geo.out patching file check/TP04sol.cas patching file check/TP06sol.cas patching file check/TP08sol.cas.out1 patching file check/TP11sol.cas.out1 patching file check/TP12sol.cas.out1 patching file check/TP13sol.cas.out1
comment:61 Changed 7 years ago by
 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
 Description modified (diff)
comment:63 Changed 7 years ago by
 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
 Description modified (diff)
 Status changed from needs_work to needs_review
comment:65 Changed 7 years ago by
 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
 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
In spkginstall
you should properly document the reason why you add disablepari
: 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" disablegui disablegmpxx
There is also this line:
echo >&2 "Error installing libGAP."
In the giacpy spkginstall
, you can remove
sage setup.py build_ext if [ $? ne 0 ]; then exit 1 fi
comment:68 Changed 7 years ago by
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
.
comment:69 Changed 7 years ago by
Side comment about PARI support: it should be possible to patch giac such that it uses PARI without initializing PARI.
comment:70 Changed 7 years ago by
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 disablepari.
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.
comment:71 Changed 7 years ago by
 Commit changed from 12dff8c3f5596dba049f9bde9ec23482979a94b3 to 88d4983ff908f2db3e8c272a7fd9330cabf47da1
comment:72 Changed 7 years ago by
 Commit changed from 88d4983ff908f2db3e8c272a7fd9330cabf47da1 to 761bcc1e6cd51adc7b1b187cc4023ca87b0506ae
Branch pushed to git repo; I updated commit sha1. New commits:
761bcc1  update to giacpy 0.4.3. upstream changes:

comment:73 Changed 7 years ago by
 Description modified (diff)
 Status changed from needs_work to needs_review
a copy of the giacpy 0.4.2 vs 0.4.3 diff file:
https://www.imjprg.fr/~frederic.han/xcas/giacpy/sage/giacpy0.4.2_0.4.3.diff
comment:74 followup: ↓ 75 Changed 7 years ago by
Hello, about pari support in the giac spkg. I saw your thread on paridevel and made some tests.
with the following patch for giac:
 a/src/pari.cc 20140702 11:05:07.000000000 +0200 +++ b/src/pari.cc 20141003 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
comment:75 in reply to: ↑ 74 ; followup: ↓ 76 Changed 7 years ago by
Replying to frederichan:
Hello, about pari support in the giac spkg. I saw your thread on paridevel and made some tests.
with the following patch for giac:
 a/src/pari.cc 20140702 11:05:07.000000000 +0200 +++ b/src/pari.cc 20141003 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.
comment:76 in reply to: ↑ 75 ; followup: ↓ 79 Changed 7 years ago by
Replying to jdemeyer:
Replying to frederichan:
Hello, about pari support in the giac spkg. I saw your thread on paridevel and made some tests.
with the following patch for giac:
 a/src/pari.cc 20140702 11:05:07.000000000 +0200 +++ b/src/pari.cc 20141003 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.ujfgrenoble.fr/XCAS/viewtopic.php?f=4&t=1539
The current status is that the patch is included in the upstream source 1.1.2 08Oct2014 16:45. (it is not a frozen source)
http://wwwfourier.ujfgrenoble.fr/~parisse/giac/giac1.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.
comment:77 Changed 7 years ago by
 Commit changed from 761bcc1e6cd51adc7b1b187cc4023ca87b0506ae to 3874ac27827ebc8b7ced212fff21f3d35d23faea
Branch pushed to git repo; I updated commit sha1. New commits:
3874ac2  Enable pari support in the spkg, and update giacpy accordingly.

comment:78 Changed 7 years ago by
 Description modified (diff)
New commits:
3874ac2  Enable pari support in the spkg, and update giacpy accordingly.

comment:79 in reply to: ↑ 76 ; followups: ↓ 81 ↓ 82 Changed 7 years ago by
comment:80 Changed 7 years ago by
 Commit changed from 3874ac27827ebc8b7ced212fff21f3d35d23faea to d0cee55ac0759159ff985e2f3ab645310a174aba
Branch pushed to git repo; I updated commit sha1. New commits:
d0cee55  add missing patch to the git tree

comment:81 in reply to: ↑ 79 ; followup: ↓ 83 Changed 7 years ago by
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. giac1.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.
comment:82 in reply to: ↑ 79 Changed 7 years ago by
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 giac1.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.
comment:83 in reply to: ↑ 81 Changed 7 years ago by
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. giac1.1.2.tar.gz) and will be updated without renaming.
Are you sure? I am asking because http://wwwfourier.ujfgrenoble.fr/~parisse/giac/giac_frozen.tgz points to giac1.1.2.tar.gz
I would like some clarity about this. If giac1.1.2
really is the latest version, that's obviously the version you should use.
comment:84 followup: ↓ 85 Changed 7 years ago by
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.
comment:85 in reply to: ↑ 84 Changed 7 years ago by
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.
comment:86 followup: ↓ 87 Changed 7 years ago by
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.28.
comment:87 in reply to: ↑ 86 Changed 7 years ago by
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 (giac1.1.28.tar.gz
)? Or, you could drop version numbers altogether and use dates (giac20141009.tar.gz
) like some other projects do.
But absolutely: never change a released tarball, no matter how bad/broken it is.
comment:88 followup: ↓ 90 Changed 7 years ago by
How do you add a subsubsubrelease number or date to the tarball with autotools and make dist?
comment:89 Changed 7 years ago by
I would even suggest to use Semantic Versioning instead. Then changing the 3rd number ("patch version") would be enough for bugfixes.
comment:90 in reply to: ↑ 88 Changed 7 years ago by
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.
comment:91 Changed 7 years ago by
is there a way to remove my name from the cc list? There is too much traffic for that ticket.
comment:92 followup: ↓ 93 Changed 7 years ago by
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
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 regenerate all the makefiles etc?
(and certainly you also need to modify the dist
target in the toplevel Makefile
to reflect the use of REVNUM
)
comment:94 Changed 7 years ago by
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 followup: ↓ 96 Changed 7 years ago by
I have asked Bernard to not change the 1.1.2 tar ball anymore, so I will package it after confirmation. http://xcas.e.ujfgrenoble.fr/XCAS/viewtopic.php?f=8&t=1537&p=7522#p7522
comment:96 in reply to: ↑ 95 Changed 7 years ago by
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.ujfgrenoble.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 followup: ↓ 98 Changed 7 years ago by
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
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 readymade tarballs.
comment:99 followup: ↓ 100 Changed 7 years ago by
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 giacYYYYMMDD.tar.bz2.
comment:100 in reply to: ↑ 99 Changed 7 years ago by
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 giacYYYYMMDD.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 followups: ↓ 102 ↓ 110 Changed 7 years ago by
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
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...
comment:103 followup: ↓ 104 Changed 7 years ago by
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
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
[...] Noncommercial 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, nonexclusive, personal, nontransferable and royaltyfree 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 noncommercial 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 followup: ↓ 106 Changed 7 years ago by
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 ; followup: ↓ 109 Changed 7 years ago by
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.
comment:107 Changed 7 years ago by
I believe that the situation would be less confusing if the current source tarball was not numbered (ex: giacsnapshot.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 dpkgbuildpackage it creates a giac_1.1.28.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
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://wwwfourier.ujfgrenoble.fr/~parisse/debian/dists/stable/main/source/
comment:109 in reply to: ↑ 106 ; followup: ↓ 111 Changed 7 years ago by
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 "giac1.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
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 nonfrozen version.
comment:111 in reply to: ↑ 109 ; followup: ↓ 112 Changed 7 years ago by
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 "giac1.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 redistributors 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 redistributors to see the source of x.y.z: instead they are shown something modified!
comment:112 in reply to: ↑ 111 ; followup: ↓ 114 Changed 7 years ago by
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 redistributors 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 redistributors 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
Just to say that the giac_1.1.28.tar.gz would be clear but not so easy to handle for a packager because it often means upstreamsourcepackageversion 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.zw packages and the current source with anothername. (or the last one and announce the packages as prerelease)
comment:114 in reply to: ↑ 112 ; followup: ↓ 118 Changed 7 years ago by
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 redistributors 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 redistributors still copied the source from the author.
redistributors 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 followup: ↓ 116 Changed 7 years ago by
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.
comment:116 in reply to: ↑ 115 Changed 7 years ago by
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.
comment:117 Changed 7 years ago by
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 ; followup: ↓ 119 Changed 7 years ago by
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.
comment:119 in reply to: ↑ 118 ; followup: ↓ 120 Changed 7 years ago by
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.
comment:120 in reply to: ↑ 119 Changed 7 years ago by
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.
comment:121 followup: ↓ 122 Changed 7 years ago by
@dimpase: IANAL, but I do agree with jdemeyer and parisse. Releasing a (totally selfauthored) 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 ; followup: ↓ 125 Changed 7 years ago by
Replying to jondo:
@dimpase: IANAL, but I do agree with jdemeyer and parisse. Releasing a (totally selfauthored) 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 followup: ↓ 124 Changed 7 years ago by
 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.zt 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
Replying to frederichan:
My feeling is that for future versions x.y.z being a link to the first stable x.y.zt 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.
comment:125 in reply to: ↑ 122 Changed 7 years ago by
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).
comment:126 Changed 7 years ago by
Hi all, bernard started a x.y.zt http://wwwfourier.ujfgrenoble.fr/~parisse/debian/dists/stable/main/source/ I will have a look at it.
comment:127 Changed 7 years ago by
 Commit changed from d0cee55ac0759159ff985e2f3ab645310a174aba to 12e93092b6fa4ff9b93e3cb7e74f56196d7b499b
comment:128 Changed 7 years ago by
 Description modified (diff)
Now working with a spkgsrc 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 giac1.1.2.10.tar.gz.
comment:129 Changed 7 years ago by
 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
 Commit changed from d78b1f26d8929e947e14b0469b016d8dfc3326e5 to d6e7099f8c1da13157b1f3e8aab6223bdf8bc1ca
Branch pushed to git repo; I updated commit sha1. New commits:
d6e7099  adjust spkgsrc and rebuilt pkg.

comment:131 Changed 7 years ago by
 Status changed from needs_work to needs_review
comment:132 Changed 7 years ago by
Just my 2 cents: public/giac_spkg still has
Source file (giacx.y.z.tar.gz) in: http://wwwfourier.ujfgrenoble.fr/~parisse/giac/
I think this should be updated.
comment:133 Changed 7 years ago by
 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
 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 6 years ago by
 Commit changed from 7de31abb1ca2c4689432c9fbb62efb158c309c47 to e8f10420527816299e7373cf1f861646727f303a
Branch pushed to git repo; I updated commit sha1. New commits:
e8f1042  update giac to 1.1.315

comment:136 Changed 6 years ago by
 Description modified (diff)
comment:137 Changed 6 years ago by
Is there still anything missing (besides giac_1.1.47.tar.gz already being available), or is this now ready for the reviewers?
comment:138 Changed 6 years ago by
 Commit changed from e8f10420527816299e7373cf1f861646727f303a to 1e70957cd546333a2be69d7ec86d321218112c91
Branch pushed to git repo; I updated commit sha1. New commits:
1e70957  update to upstream 1.1.47. And fix the patches of the check suite accordingly.

comment:139 Changed 6 years ago by
 Description modified (diff)
comment:140 Changed 6 years ago by
 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 6 years ago by
If you adapt the patch like I said, then I will continue my review.
comment:142 Changed 6 years ago by
 Commit changed from 1e70957cd546333a2be69d7ec86d321218112c91 to fa05b47f7622dc3ee139ebfb7cf4daf679aeb776
comment:143 Changed 6 years ago by
 Description modified (diff)
comment:144 Changed 6 years ago by
 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 6 years ago by
 Description modified (diff)
comment:146 Changed 6 years ago by
 Status changed from needs_review to needs_work
The giacpy testsuite doesn't compile:
Successfully installed giacpy0.4.5 Running the test suite for giacpy0.4.5... too many failed tests, not using stored timings Running doctests with ID 201503021928386f231793. 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/sagegit/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 2128, in __call__ doctests, extras = self.source.create_doctests(sage_namespace) File "/usr/local/src/sagegit/local/lib/python2.7/sitepackages/sage/doctest/sources.py", line 661, in create_doctests load(filename, namespace) # errors raised here will be caught in DocTestTask File "/usr/local/src/sagegit/local/lib/python2.7/sitepackages/sage/repl/load.py", line 294, in load exec(load_cython(fpath), globals) File "/usr/local/src/sagegit/local/lib/python2.7/sitepackages/sage/repl/load.py", line 65, in load_cython mod, dir = cython(name, compile_message=True, use_cache=True) File "/usr/local/src/sagegit/local/lib/python2.7/sitepackages/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 6 years ago by
 Commit changed from fa05b47f7622dc3ee139ebfb7cf4daf679aeb776 to bb9cbfe528796c3f209da30fe67da30dc2c6cfb2
comment:148 Changed 6 years ago by
 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 forcelib giacpy.pyx
comment:149 Changed 6 years ago by
 Status changed from needs_review to needs_work
small built failure with pari 2.8. waiting a little for upstream modifications. http://xcas.e.ujfgrenoble.fr/XCAS/viewtopic.php?f=4&t=1634
comment:150 Changed 6 years ago by
 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.315

cee1552  update to upstream 1.1.47. And fix the patches of the check suite accordingly.

ff9aefd  update to upstream 1.1.410

7585705  update checksum

75d15ac  rewrite the nofltk patches. Put graphic options in several source check files to obtain the same

71c346c  add forcelib in spkgcheck to not try to compile giacpy.pyx during tests

245bc62  update giac to 1.2.013 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 6 years ago by
 Description modified (diff)
comment:152 Changed 6 years ago by
 Description modified (diff)
comment:153 Changed 6 years ago by
 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 6 years ago by
 Status changed from needs_work to needs_review
So I have updated to giac 1.2.013, and giacpy 0.4.6.
comment:155 Changed 6 years ago by
 Description modified (diff)
comment:156 Changed 6 years ago by
 Description modified (diff)
comment:157 followup: ↓ 160 Changed 6 years ago by
 Milestone changed from sage6.4 to sage6.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 6 years ago by
The changes look good to me, so if it actually works, it's good to go.
comment:159 Changed 6 years ago by
 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 6 years ago by
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
comment:161 Changed 6 years ago by
I have tested to put an: export CFLAGS+="I$SAGE_SRC/sage/ext" in giacpy's spkginstall, it solves the problem. Do you recommand something else?
comment:162 Changed 6 years ago by
 Commit changed from 8b1049f30bc0bcb542d29e336ce64402def0bc52 to 8f7db49a3df0ffea99692a18fad5bf9d300294a7
Branch pushed to git repo; I updated commit sha1. New commits:
8f7db49  adapts CFLAGS in spkginstall because of ccobject.h not found due to cimport Integer

comment:163 Changed 6 years ago by
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 6 years ago by
 Commit changed from 8f7db49a3df0ffea99692a18fad5bf9d300294a7 to 2e5cd0ee3dc0df98cbb1d1f5a1a3dc9cc0d1a62a
comment:165 Changed 6 years ago by
 Description modified (diff)
comment:166 Changed 6 years ago by
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.21) (GCC) **************************************************** Deleting /home/fred/dev/sage/local/lib/python/sitepackages/giacpy* running install running build running build_ext cythoning giacpy.pyx to giacpy.cpp building 'giacpy' extension creating build creating build/temp.linuxx86_642.7 gcc fnostrictaliasing 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.linuxx86_642.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 [Wunknownpragmas] #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 6 years ago by
You might want to wait for #18494, which should make it easier to install external packages using the Sage library.
comment:168 Changed 6 years ago by
See #18514 for a package with similar problems. The same trick should work here.
comment:169 Changed 6 years ago by
 Dependencies set to #18494
comment:170 Changed 6 years ago by
 Description modified (diff)
comment:171 Changed 6 years ago by
 Description modified (diff)
comment:172 Changed 6 years ago by
 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
So I have updated setup.py to giacpy0.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
At least part of the problem is this Cython bug: http://trac.cython.org/ticket/851
comment:175 Changed 6 years ago by
Can you try explicit imports instead of import *
and see if that helps?
comment:176 Changed 6 years ago by
Thank you! it improves things. I will clean and test more.
comment:177 Changed 6 years ago by
 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
 Description modified (diff)
comment:179 Changed 6 years ago by
 Status changed from needs_work to needs_review
comment:180 Changed 6 years ago by
 Status changed from needs_review to positive_review
comment:181 Changed 6 years ago by
 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
 Commit c7f6087b946934ed18f25734a635e805d5b064a3 deleted
Many thanks to all the participants.
comment:183 Changed 6 years ago by
comment:184 Changed 5 years ago by
 Cc jondo removed
a copy of the SPKG.txt file included.