Opened 7 years ago

Closed 3 years ago

Last modified 3 years ago

#12375 closed enhancement (fixed)

Create a giac package

Reported by: frederichan Owned by: tbd
Priority: minor Milestone: sage-6.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) Commit:
Dependencies: #18494 Stopgaps:

Description (last modified by frederichan)

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

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

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

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

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

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

Attachments (2)

SPKG.txt (1.5 KB) - added by frederichan 7 years ago.
a copy of the SPKG.txt file included.
builderr.log (23.1 KB) - added by dimpase 4 years ago.
log of the build attempt (on Sage 6.3.beta5), OSX 10.9

Download all attachments as: .zip

Change History (186)

comment:1 Changed 7 years ago by frederichan

  • Description modified (diff)

comment:2 Changed 7 years ago by frederichan

  • Type changed from PLEASE CHANGE to enhancement

comment:3 Changed 7 years ago by frederichan

  • Status changed from new to needs_review

Changed 7 years ago by frederichan

a copy of the SPKG.txt file included.

comment:4 Changed 7 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 7 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:6 Changed 6 years ago by jdemeyer

Please fill in your real name as Author.

comment:7 Changed 6 years ago by frederichan

  • Authors set to Han Frederic

comment:8 Changed 6 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 6 years ago by frederichan

  • Description modified (diff)

upgrade the spkg to the current version of giac: 1.0.0

comment:10 Changed 6 years ago by zimmerma

  • Cc zimmerma added

comment:11 Changed 5 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:12 Changed 5 years ago by frederichan

Update to version 1.1 of giac.

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

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

comment:13 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:14 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:15 follow-up: Changed 4 years ago by jondo

  • 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 4 years ago by frederichan

Replying to jondo:

Would this make giac available in the provided Sage VMs?

(Context: Solving rational inequality should give simplified result)

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

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

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

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

Best regards

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

comment:17 Changed 4 years ago by frederichan

  • Description modified (diff)

comment:18 Changed 4 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: Changed 4 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 4 years ago by dimpase (previous) (diff)

Changed 4 years ago by dimpase

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

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

Replying to dimpase:

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

See the attached log.

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

Best regards, Frederic

comment:21 Changed 4 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 4 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

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 4 years ago by zimmerma

  • Cc zimmerma removed

comment:24 Changed 4 years ago by frederichan

  • Description modified (diff)

comment:25 follow-up: Changed 4 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 4 years ago by dimpase

Replying to Han Frederic:

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

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

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

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

comment:27 follow-up: Changed 4 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 4 years ago by dimpase

Replying to Han Frederic:

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

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

...

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

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

...

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

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

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

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

comment:29 follow-up: Changed 4 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 4 years ago by dimpase

Replying to Han Frederic:

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

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

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

so it blocks the use of tr1/unordered_map.

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

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

does it works for you also?

yes it does.

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

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

comment:31 follow-up: Changed 4 years ago by frederichan

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

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

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

I have put the spkg scripts there:

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

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

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

and the spkg scripts there:

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

is it the correct way to distribute new spkg?

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

comment:32 Changed 4 years ago by frederichan

  • Description modified (diff)

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

Replying to Han Frederic:

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

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

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

I have put the spkg scripts there:

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

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

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

and the spkg scripts there:

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

is it the correct way to distribute new spkg?

Did you look at

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

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

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

comment:34 Changed 4 years ago by frederichan

  • Branch set to u/HanFrederic/submit_a_giac__spkg

comment:35 Changed 4 years ago by frederichan

  • Branch u/HanFrederic/submit_a_giac__spkg deleted

comment:36 Changed 4 years ago by frederichan

  • Branch set to public/giac_spkg

u/Han Frederic/submit_a_giacspkg

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

comment:37 Changed 4 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
    self.git.echo.push('trac', 'HEAD:'+remote_branch)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 355, in meth
    return self.execute(git_cmd, *args, **kwds)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 98, in execute
    popen_stderr=subprocess.PIPE)
  File "/usr/local/sage-6.2/local/lib/python2.7/site-packages/git_trac/git_interface.py", line 262, in _run
    raise GitError(result)
git_trac.git_error.GitError: git returned with non-zero exit code (128) when executing "git push trac HEAD:u/Han Frederic/giac_new_style_spkg"
    STDERR: fatal: remote part of refspec is not a valid name in HEAD:u/Han Frederic/giac_new_style_spkg

comment:38 Changed 4 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 4 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 4 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 4 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 4 years ago by git

  • Commit set to 9562050fcc8774cbfeeaa88479cd8eb5733a45a7

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

9562050add giac and giacpy pkg scripts

comment:43 Changed 4 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 4 years ago by dimpase (previous) (diff)

comment:44 Changed 4 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 4 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:46 follow-ups: Changed 4 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 4 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?

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

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

comment:48 in reply to: ↑ 46 Changed 4 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 4 years ago by jdemeyer

  • Description modified (diff)
  • Summary changed from submit a giac spkg to Create a giac package

comment:50 Changed 4 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 4 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 4 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 4 years ago by frederichan

  • Description modified (diff)

comment:54 Changed 4 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 4 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 4 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 4 years ago by frederichan

  • Description modified (diff)

comment:58 Changed 4 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.
94cc750disable pari support to compile the c++ libgiac and modify checks accordingly
753d8d9update to giacpy 0.4.1 version. (version of giacpy without setup_sage_signal_handler)
ee6258dFixes in the pexpect giac interfaces doctests.

comment:59 Changed 4 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 4 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 4 years ago by git

  • Commit changed from ee6258dd4b92e2ec0c4fb5ad24422564344cbe3d to d1b5cfdb0d0c3354462ffcef95183d41763ba60f

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

d1b5cfdclean commented code, unapplied patches and fuz in patch

comment:62 Changed 4 years ago by frederichan

  • Description modified (diff)

comment:63 Changed 4 years ago by git

  • Commit changed from d1b5cfdb0d0c3354462ffcef95183d41763ba60f to 12dff8c3f5596dba049f9bde9ec23482979a94b3

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

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

comment:64 Changed 4 years ago by frederichan

  • Description modified (diff)
  • Status changed from needs_work to needs_review

comment:65 Changed 4 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 4 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 4 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


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

comment:68 Changed 4 years ago by jdemeyer

There are 2 other doctest failures:

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

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

# optional - giac

instead of #optional.

Last edited 4 years ago by jdemeyer (previous) (diff)

comment:69 Changed 4 years ago by jdemeyer

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

comment:70 Changed 4 years ago by frederichan

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

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

comment:71 Changed 4 years ago by git

  • Commit changed from 12dff8c3f5596dba049f9bde9ec23482979a94b3 to 88d4983ff908f2db3e8c272a7fd9330cabf47da1

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

90ab5edclean up other versions of giacpy before installation.
d0d9d47Update comments in the giac pkg.
ae47680remove unecessary lines in giacpy spkg-install
88d4983Fixes in doctests of the pexpect giac interface

comment:72 Changed 4 years ago by git

  • Commit changed from 88d4983ff908f2db3e8c272a7fd9330cabf47da1 to 761bcc1e6cd51adc7b1b187cc4023ca87b0506ae

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

761bcc1update to giacpy 0.4.3. upstream changes:

comment:73 Changed 4 years ago by frederichan

  • Description modified (diff)
  • Status changed from needs_work to needs_review

comment:74 follow-up: Changed 4 years ago by frederichan

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

with the following patch for giac:

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

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

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

Cheers

comment:75 in reply to: ↑ 74 ; follow-up: Changed 4 years ago by jdemeyer

Replying to frederichan:

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

with the following patch for giac:

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

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

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

Why 1 year?

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

No.

comment:76 in reply to: ↑ 75 ; follow-up: Changed 4 years ago by frederichan

Replying to jdemeyer:

Replying to frederichan:

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

with the following patch for giac:

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

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

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

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

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

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

Why 1 year?

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

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

No.

comment:77 Changed 4 years ago by git

  • Commit changed from 761bcc1e6cd51adc7b1b187cc4023ca87b0506ae to 3874ac27827ebc8b7ced212fff21f3d35d23faea

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

3874ac2Enable pari support in the spkg, and update giacpy accordingly.

comment:78 Changed 4 years ago by frederichan

  • Description modified (diff)

New commits:

3874ac2Enable pari support in the spkg, and update giacpy accordingly.

comment:79 in reply to: ↑ 76 ; follow-ups: Changed 4 years ago by jdemeyer

Replying to frederichan:

it is not a frozen source

What does this sentence mean?

comment:80 Changed 4 years ago by git

  • Commit changed from 3874ac27827ebc8b7ced212fff21f3d35d23faea to d0cee55ac0759159ff985e2f3ab645310a174aba

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

d0cee55add missing patch to the git tree

comment:81 in reply to: ↑ 79 ; follow-up: Changed 4 years ago by jondo

Replying to jdemeyer:

it is not a frozen source

What does this sentence mean?

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

Last edited 4 years ago by jondo (previous) (diff)

comment:82 in reply to: ↑ 79 Changed 4 years ago by frederichan

Replying to jdemeyer:

Replying to frederichan:

it is not a frozen source

What does this sentence mean?

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

comment:83 in reply to: ↑ 81 Changed 4 years ago by jdemeyer

Replying to jondo:

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

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

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

comment:84 follow-up: Changed 4 years ago by parisse

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

comment:85 in reply to: ↑ 84 Changed 4 years ago by jdemeyer

Replying to parisse:

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

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

comment:86 follow-up: Changed 4 years ago by parisse

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

comment:87 in reply to: ↑ 86 Changed 4 years ago by jdemeyer

Replying to parisse:

It takes too much time to change version number.

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

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

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

comment:88 follow-up: Changed 4 years ago by parisse

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

comment:89 Changed 4 years ago by jondo

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

Last edited 4 years ago by jondo (previous) (diff)

comment:90 in reply to: ↑ 88 Changed 4 years ago by dimpase

Replying to parisse:

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

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

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

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

comment:91 Changed 4 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: Changed 4 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 4 years ago by dimpase

Replying to parisse:

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

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

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

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

comment:94 Changed 4 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: Changed 4 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 4 years ago by frederichan (previous) (diff)

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

Replying to frederichan:

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

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

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

comment:97 follow-up: Changed 4 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 4 years ago by jdemeyer

Replying to parisse:

jdemeyer: not a very constructive comment.

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

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

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

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

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

comment:99 follow-up: Changed 4 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 4 years ago by dimpase

Replying to parisse:

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

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

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

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

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

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

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

comment:101 follow-ups: Changed 4 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 4 years ago by dimpase

Replying to parisse:

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

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

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

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

comment:103 follow-up: Changed 4 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 4 years ago by dimpase

Replying to parisse:

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

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

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

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

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

comment:105 follow-up: Changed 4 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: Changed 4 years ago by dimpase

Replying to parisse:

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

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

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

comment:107 Changed 4 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 4 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: Changed 4 years ago by jdemeyer

Replying to dimpase:

You seem to be violating GPL, too:

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

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

Replying to parisse:

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

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

comment:111 in reply to: ↑ 109 ; follow-up: Changed 4 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

You seem to be violating GPL, too:

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

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

comment:112 in reply to: ↑ 111 ; follow-up: Changed 4 years ago by jdemeyer

Replying to dimpase:

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

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

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

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

comment:113 Changed 4 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: Changed 4 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

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

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

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

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

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

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

comment:115 follow-up: Changed 4 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 4 years ago by parisse (previous) (diff)

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

Replying to parisse:

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

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

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

comment:119 in reply to: ↑ 118 ; follow-up: Changed 4 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

the author can violate this rather easily.

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

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

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

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

Replying to dimpase:

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

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

comment:121 follow-up: Changed 4 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: Changed 4 years ago by dimpase

Replying to jondo:

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

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

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

comment:123 follow-up: Changed 4 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 4 years ago by dimpase

Replying to frederichan:

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

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

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

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

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

Replying to dimpase:

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

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

comment:126 Changed 4 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 4 years ago by git

  • Commit changed from d0cee55ac0759159ff985e2f3ab645310a174aba to 12e93092b6fa4ff9b93e3cb7e74f56196d7b499b

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

16aedc1giac 1.1.2-10 + add spkg-src + add patch for pari ifactor under osx
137487fgiacpy 0.4.5: Fix in __call__, try, sig_on and giac errors such as pari lock messages.
12e9309improve spkg-src

comment:128 Changed 4 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)

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

comment:129 Changed 4 years ago by git

  • Commit changed from 12e93092b6fa4ff9b93e3cb7e74f56196d7b499b to d78b1f26d8929e947e14b0469b016d8dfc3326e5

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

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

comment:130 Changed 4 years ago by git

  • Commit changed from d78b1f26d8929e947e14b0469b016d8dfc3326e5 to d6e7099f8c1da13157b1f3e8aab6223bdf8bc1ca

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

d6e7099adjust spkg-src and rebuilt pkg.

comment:131 Changed 4 years ago by frederichan

  • Status changed from needs_work to needs_review

comment:132 Changed 4 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 4 years ago by git

  • Commit changed from d6e7099f8c1da13157b1f3e8aab6223bdf8bc1ca to ed40da723eaa82d05a45dac32564de879bac9de8

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

ed40da7update upstream source link in SPKG.txt

comment:134 Changed 4 years ago by git

  • Commit changed from ed40da723eaa82d05a45dac32564de879bac9de8 to 7de31abb1ca2c4689432c9fbb62efb158c309c47

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

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

comment:135 Changed 4 years ago by git

  • Commit changed from 7de31abb1ca2c4689432c9fbb62efb158c309c47 to e8f10420527816299e7373cf1f861646727f303a

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

e8f1042update giac to 1.1.3-15

comment:136 Changed 4 years ago by frederichan

  • Description modified (diff)

comment:137 Changed 4 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 4 years ago by git

  • Commit changed from e8f10420527816299e7373cf1f861646727f303a to 1e70957cd546333a2be69d7ec86d321218112c91

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

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

comment:139 Changed 4 years ago by frederichan

  • Description modified (diff)

New commits:

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

New commits:

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

comment:140 Changed 4 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 4 years ago by jdemeyer

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

comment:142 Changed 4 years ago by git

  • Commit changed from 1e70957cd546333a2be69d7ec86d321218112c91 to fa05b47f7622dc3ee139ebfb7cf4daf679aeb776

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

105298dupdate to upstream 1.1.4-10
add5ebcupdate checksum
fa05b47rewrite the nofltk patches. Put graphic options in several source check files to obtain the same

comment:143 Changed 4 years ago by frederichan

  • Description modified (diff)

comment:144 Changed 4 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 4 years ago by jdemeyer

  • Description modified (diff)

comment:146 Changed 4 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
    load(filename, namespace) # errors raised here will be caught in DocTestTask
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/repl/load.py", line 294, in load
    exec(load_cython(fpath), globals)
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/repl/load.py", line 65, in load_cython
    mod, dir = cython(name, compile_message=True, use_cache=True)
  File "/usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/misc/cython.py", line 493, in cython
    raise RuntimeError("Error converting {} to C:\n{}\n{}".format(filename, log, err))
RuntimeError: Error converting ./giacpy.pyx to C:


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


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

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

comment:147 Changed 4 years ago by git

  • Commit changed from fa05b47f7622dc3ee139ebfb7cf4daf679aeb776 to bb9cbfe528796c3f209da30fe67da30dc2c6cfb2

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

f71bc55Merge git://trac.sagemath.org/sage into t/12375/public/giac_spkg
bb9cbfeadd --force-lib in spkg-check to not try to compile giacpy.pyx during tests

comment:148 Changed 4 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 3 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 3 years ago by git

  • Commit changed from bb9cbfe528796c3f209da30fe67da30dc2c6cfb2 to 3fb1480c0be6c3cb1749f7a8959fd21090aca25e

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

c66d104update SPKG.txt to announce that the french html doc was removed.
9fe3d19update giac to 1.1.3-15
cee1552update to upstream 1.1.4-7. And fix the patches of the check suite accordingly.
ff9aefdupdate to upstream 1.1.4-10
7585705update checksum
75d15acrewrite the nofltk patches. Put graphic options in several source check files to obtain the same
71c346cadd --force-lib in spkg-check to not try to compile giacpy.pyx during tests
245bc62update giac to 1.2.0-13 and patch the check suite for pari 2.8
d03267eupdate to 0.4.6. add loadgiacgen + remove PY_TYPE_CHECK
3fb1480Merge branch 'public/giac_spkg' of git://trac.sagemath.org/sage into t/12375/public/giac_spkg

comment:151 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:152 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:153 Changed 3 years ago by git

  • Commit changed from 3fb1480c0be6c3cb1749f7a8959fd21090aca25e to b64564a9d9db35532abef430527c6571d9f33f4b

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

b64564aimprove the pari check patch to be less version dependent

comment:154 Changed 3 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 3 years ago by frederichan

  • Description modified (diff)

comment:156 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:157 follow-up: Changed 3 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 3 years ago by jdemeyer

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

comment:159 Changed 3 years ago by git

  • Commit changed from b64564a9d9db35532abef430527c6571d9f33f4b to 8b1049f30bc0bcb542d29e336ce64402def0bc52

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

8b1049fadd type files. (optional)

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

Replying to jdemeyer:

OK, let's try again to review this.

Thank you!

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

comment:161 Changed 3 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 3 years ago by git

  • Commit changed from 8b1049f30bc0bcb542d29e336ce64402def0bc52 to 8f7db49a3df0ffea99692a18fad5bf9d300294a7

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

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

comment:163 Changed 3 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 3 years ago by git

  • Commit changed from 8f7db49a3df0ffea99692a18fad5bf9d300294a7 to 2e5cd0ee3dc0df98cbb1d1f5a1a3dc9cc0d1a62a

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

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

comment:165 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:166 Changed 3 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 3 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 3 years ago by jdemeyer

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

comment:169 Changed 3 years ago by jdemeyer

  • Dependencies set to #18494

comment:170 Changed 3 years ago by jdemeyer

  • Description modified (diff)

comment:171 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:172 Changed 3 years ago by git

  • Commit changed from 2e5cd0ee3dc0df98cbb1d1f5a1a3dc9cc0d1a62a to 31a89c52f35b4bf385de9d6fc98be54a9f972616

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

31a89c5test of update setup.py to use sage 6.8 include path

comment:173 Changed 3 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 3 years ago by jdemeyer

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

comment:175 Changed 3 years ago by jdemeyer

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

comment:176 Changed 3 years ago by frederichan

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

comment:177 Changed 3 years ago by git

  • Commit changed from 31a89c52f35b4bf385de9d6fc98be54a9f972616 to c7f6087b946934ed18f25734a635e805d5b064a3

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

c7f6087update giacpy to 0.4.8 (cleanup code)

comment:178 Changed 3 years ago by frederichan

  • Description modified (diff)

comment:179 Changed 3 years ago by frederichan

  • Status changed from needs_work to needs_review

comment:180 Changed 3 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:181 Changed 3 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 3 years ago by frederichan

  • Commit c7f6087b946934ed18f25734a635e805d5b064a3 deleted

Many thanks to all the participants.

comment:183 Changed 3 years ago by jdemeyer

  • Authors changed from Han Frederic to Frederic Han

comment:184 Changed 3 years ago by jondo

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