[sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Actually OSX is foobar'ed even then, Apple's ancient openssl just doesn't support TLSv1.2. Some sites are already requiring that: osx:~ vbraun$ openssl s_client -connect www.kernel.org:443 CONNECTED(0003) write:errno=54 On Monday, November 21, 2016 at 12:21:31 PM UTC+1, Emmanuel Charpentie

Re: [sage-devel] Checking out old branches

path/to/sage-7.4, it checks >> out to a sibling folder /path/to/sage-7.4_merge_tree. Automating it is a >> bit more complicated though; if the merge fails and the user has to correct >> it manually, you either need a separate command to pull back into the main >> reposit

Re: [sage-devel] Checking out old branches

Thats a wrong-way merge and is confusing if one ever wants to understand the history of the ticket. The convention is that the feature branch is first, and you merge in dependencies. On Sunday, November 20, 2016 at 2:31:57 AM UTC+1, David Roe wrote: > > I've implemented a new git-trac command

[sage-devel] Re: Checking out old branches

much easier to just do a separate clone of the repo. And its completely standard git commands. On Friday, November 18, 2016 at 9:40:15 AM UTC+1, David Roe wrote: > > > > On Fri, Nov 18, 2016 at 2:45 AM, Volker Braun > wrote: > >> On Friday, November 18, 20

[sage-devel] Re: Checking out old branches

On Friday, November 18, 2016 at 8:12:32 AM UTC+1, David Roe wrote: > > Create a new git trac subcommand to replace `git trac checkout 1234`, say > `git trac old 1234`. This would fetch the branch, check it out into a > completely separate folder within ($SAGE_ROOT/merge_tree or something), > me

[sage-devel] Re: "Tri bool"

Exception don't handle the Indeterminate or True => True case. If you really need the entire logic then the imho best solution is to be explicit; Define values True3, False3, Undefined3 that are independent of booleans and function Bool3.and(), Bool3.or(), ... for logic. On Wednesday, November

[sage-devel] Re: why chrome kiosk mode in sage appliance??

The recommended (for power users) way to run the virtual machine is using their host browser, just go to http://localhost:8000. This requires a non-broken windows networking stack, though (and various dodgy windows programs can interfere). In the kiosk mode you can still go back,e.g. open a not

Re: [sage-devel] Re: jsmol.js

Its not a proper notebook extension; The code is in src/sage/repl/display/jsmol_iframe.py -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@

Re: [sage-devel] Re: jsmol.js

On Tuesday, November 1, 2016 at 2:31:00 PM UTC-4, William wrote: > > This is happening in the web browser Its actually happening in an iframe inside the web browser, so it doesn't have jupyter's module loader. Afair jsmol just doesn't work at all in the same namespace with juypter, without the

Re: [sage-devel] Re: jsmol.js

On Tuesday, November 1, 2016 at 12:16:58 PM UTC-4, William wrote: > > Your iframe hack doesn't respect Jupyter's base url options, which is > the (only) problem for both Jupyterhub and SageMathCloud. Because it can't, the compute kernel does not (and arguably should not) know about the base ur

Re: [sage-devel] Re: jsmol.js

Jupyter(-hub) expects the worksheet to be self-contained, so the entire graphics data needs to be embedded without any further calls to the backend. Thats the only way that you can then share the notebook on nbviewer or github, say, and graphics still works. Jmol's architecture is fundamentally

[sage-devel] Re: jsmol.js

+1 On Tuesday, November 1, 2016 at 6:35:12 AM UTC-4, Eric Gourgoulhon wrote: > > Hi, > > A related note: there is ongoing work at > https://trac.sagemath.org/ticket/12402 > to use three.js for 3d graphics in Sage, especially in Jupyter notebook. > It is almost ready and has already features far

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

I think you are making it more difficult than it is. I'm pretty sure our binaries already depend on openssl being installed, and we do this under the GPL system library exception. We just can't ship our own openssl (nor would I want to). So we may just as well include libcurl, linked to the sys

[sage-devel] Re: [sage-support] sage-7.4-Ubuntu_16.04-x86_64.tar.bz2 fails to install correctly

https://trac.sagemath.org/ticket/21772 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email t

[sage-devel] Re: add curl as a standard package

On Wednesday, October 26, 2016 at 2:40:42 AM UTC-4, Emmanuel Charpentier wrote: > > This issue is *distinct* from the one I'm trying to solve (iL e. satisfy > R's prerequisites). Should't you open a relevant ticket ? > Its not really a distinct issue, its a general caveat of compiling your own

[sage-devel] Re: add curl as a standard package

One issue with curl is that you sooner or later will need the root certificates to use it, namely when you start downloading from a https site. E.g. in hashstack I recently added the root certs: https://github.com/hashdist/hashstack/issues/969 This issue already faces us with openssl but since

Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

I have a setup helper for jupyterhup at https://github.com/vbraun/run-jupyter-hub It might be out of date, haven't tried it with the newest version of jupyterhub. But maybe its a starting point for you... On Monday, October 24, 2016 at 7:47:15 AM UTC-4, Jori Mäntysalo wrote: > > On Sun, 23 O

Re: [sage-devel] Re: Notebook stuck on "N?" with a worksheet

Yes, with jupyterhub you can have isolation with unix users. That is, there is a login screen and people can sign in with their normal unix username/password. On Saturday, October 22, 2016 at 4:27:55 PM UTC-4, Jori Mäntysalo wrote: > > Does it have multiuser support, so that A can't see worksh

[sage-devel] Re: Notebook stuck on "N?" with a worksheet

IMHO the best solution is to stop using SageNB asap and use "sage --notebook=jupyter" On Friday, October 7, 2016 at 11:24:02 AM UTC+2, Jori Mäntysalo wrote: > > Could someone try SageNB with http://www.sis.uta.fi/~jm58660/Broken.sws > > For me that stucks when I try to evaluate the first calcu

[sage-devel] Re: Troubles communicating with Sage 7.4

This is now https://trac.sagemath.org/ticket/21743 On Saturday, October 22, 2016 at 5:01:06 AM UTC+2, Andrey Novoseltsev wrote: > > Hello, > > I need help figuring out what's going on when I am preparing Sage for > SageMathCell. > > When the script is at > > https://github.com/sagemath/sagecell/b

Re: [sage-devel] Re: trac down?

Github.com didn't resolve for me earlier, that might mess with the trac plugins... On Friday, October 21, 2016 at 8:10:41 PM UTC+2, William wrote: > > Half the internet is down right now... > > > http://gizmodo.com/this-is-probably-why-half-the-internet-shut-down-today-1788062835 > > > I

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

We do have a pc file so IMHO the best way is to rely on the output of $ pkg-config --cflags lapack -I/mnt/disk/home/release/Sage/local/include $ pkg-config --libs lapack -L/mnt/disk/home/release/Sage/local/lib -lopenblas On Thursday, October 20, 2016 at 11:12:43 PM UTC+2, François wrote: > > Th

[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

On Thursday, October 20, 2016 at 1:19:51 AM UTC+2, Sébastien Labbé wrote: > > Does this also explain the leak? > Freed memory is not immediately returned to the system (mostly because it would be hilariously slow for small allocations). Whether a one-off computation increases process memory usag

[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

PS: Write your code in a file and compile it with "cython -a myfile.pyx", that generates a html file with explanations. On Thursday, October 20, 2016 at 1:11:14 AM UTC+2, Volker Braun wrote: > > Thats the expected behavoir. Without type annotation, cython just does the

[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

Thats the expected behavoir. Without type annotation, cython just does the same as Python (create a list of 10**8 elements and iterate over). With type annotation it is a C-level for loop. On Thursday, October 20, 2016 at 12:33:47 AM UTC+2, Sébastien Labbé wrote: > > Dear sage-devel, > > Writin

Re: [sage-devel] git-trac push

On Tuesday, October 18, 2016 at 10:37:24 AM UTC+2, Daniel Krenn wrote: > > It would be nice, if the actual git errors were shown by git-trac. Is > this (easily) possible? > Doing "git-trac --log=DEBUG" probably works. Of course the ideal solution would be for main to catch errors and present a

[sage-devel] Re: Regression introduced by #21670 ?

I created https://trac.sagemath.org/ticket/21712 for this issue On Saturday, October 15, 2016 at 10:15:35 PM UTC+2, Salvatore Stella wrote: > > Dear All, > it seems that the ticket #21670 recently merged into develop makes sage > crash > on my machine, can anyone replicate this? > > In a new x

Re: [sage-devel] Milestones

I don't really use the milestones except for the sage-duplicate/invalid/wontfix which indicates that there is nothing to merge. We don't really use trac for roadmap planning so there is no real significance to milestones, I guess. On Friday, October 14, 2016 at 4:07:06 PM UTC+2, Jeroen Demeye

Re: [sage-devel] About exceptions

On Wednesday, October 12, 2016 at 4:01:51 PM UTC+2, Daniel Krenn wrote: > > There could be a ContainsCycleError which has RuntimeError as a base... > +1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop rec

Re: [sage-devel] To the attention of Nicolas M Thiéry (recursive-monkey-patch)

"sage -b" will rebuild any sage cython modules that were changed, so for your application its probably enough. It does not rebuild third-party packages or documentation. On Sunday, October 9, 2016 at 12:06:25 PM UTC+2, Emmanuel Charpentier wrote: > > Le 9 oct. 2016 12:01, "Jori Mäntysalo" > >

[sage-devel] Re: slow doctest number_field_element.pyx on my machine

I've seen that time out often on the buildbot, too. Please, somebody replace the test in there by something more reasonable. On Tuesday, October 4, 2016 at 9:53:13 PM UTC+2, Jakob Kroeker wrote: > > on my machine (fedora 23, 32 Bit) the test > > sage -t --long --warn-long 127.3 src/sage/rings/n

[sage-devel] Re: waterfall

Yes, I updated over the weekend to the buildbot nine (0.9.0rc4) which is quite different from the old one. On Monday, October 3, 2016 at 9:23:46 PM UTC+2, Jan Groenewald wrote: > > Hi > > http://build.sagemath.org/release/waterfall > > gives me > > No Such Resource > > File not found. > > > Ha

Re: [sage-devel] Re: trouble compiling latest sage development version

My suggestion would be to upgrade to xcode 10.11, and then to the newer xcode that is available on osx 10.11 only. That linker should then properly support AVX instructions. Thats also the only OS/compiler version that we have a buildbot for (or receives updates from Apple for that matter). O

Re: [sage-devel] Re: [sagemath-admins] trac not responding

I may have time next weekend to containerize the buildbot, though no promises. It does need quite a lot of disk space (the old one was about 50GB iirc) to hold all the build logs and binary builds. Whats the plan for external networking and secrets? On Tuesday, September 27, 2016 at 9:57:43 P

[sage-devel] Re: [sagemath-admins] trac not responding

Yes, both the file server files.sagemath.org and buildbot build.sagemath.org are down... On Monday, September 26, 2016 at 2:25:52 PM UTC+2, leif wrote: > > Dima Pasechnik wrote: > > On Mon, Sep 26, 2016 at 7:50 AM, Harald Schilly > > > wrote: > >> On Mon, Sep 26, 2016 at 3:51 AM, Jonathan Bo

Re: [sage-devel] Re: [sagemath-admins] trac not responding

Didn't we have that problem previously that OS updates would overwrite system config (I'm guessing thats what happened). On Monday, September 26, 2016 at 12:02:36 PM UTC+2, Dima Pasechnik wrote: > > > > On Monday, September 26, 2016 at 9:04:08 AM UTC, Volker Braun wrote:

Re: [sage-devel] Re: [sagemath-admins] trac not responding

Somebody killed unauthorized git:// over the weekend... incorrect firewall rule? On Monday, September 26, 2016 at 10:52:13 AM UTC+2, Harald Schilly wrote: > > On Mon, Sep 26, 2016 at 10:16 AM, Dima Pasechnik > wrote: > > this really has to be documented properly. > > just added to your ticket

[sage-devel] Re: [sagemath-admins] trac not responding

The buildbot is offline, too... http://build.sagedev.org There shouldn't be a connection but its certainly an odd coincidence On Sunday, September 25, 2016 at 5:22:19 PM UTC+2, William wrote: > > On Sun, Sep 25, 2016 at 8:13 AM, Dima Pasechnik > wrote: > > > > I almost cannot use either we

[sage-devel] Re: OS X testers needed

You do have an account on the OSX buildbot in case you forgot ;-) On Saturday, September 24, 2016 at 1:04:09 PM UTC+2, Jeroen Demeyer wrote: > > If you have an OS X system and want to help Sage and PARI: > > 1. Checkout the branch at https://trac.sagemath.org/ticket/21582 > > 2. Run "./sage -i -

[sage-devel] Re: Error building sage 7.3 on Fedora 24 x86_64

The easiest solution would be to install the dependencies so that Sage doesn't attempt to compile its own toolchain: http://doc.sagemath.org/html/en/installation/source.html#linux-prerequisite-installation On Thursday, September 22, 2016 at 8:45:34 PM UTC+2, Lennart Jern wrote: > > Hello, > >

[sage-devel] Re: Importing sage.libs.gap.assigned_names take a very long time

For tab completion and so on we want a list of "useful" GAP functions, excluding internal functions that are not meant for end users. Unfortunately, there isn't really a good way to get that from GAP. The best approach seems to be to look for the actually documented functions. Downside is that

[sage-devel] Re: Compilation error with linbox-1.4.2 during compilation of sage 7.4.beta4

The error is in an optional part that isn't compiled by default; I guess its the maple interface? The config contains checking for MAPLE >= 9.0... ./configure: line 18187: /bin/maple.system.type: No such file or directory found We should probably configure linbox with --with-maple=no On Mond

[sage-devel] Re: sage -br rebuilds things that were not changed

The upstream bugs are still open: https://github.com/cython/cython/issues?q=is%3Aissue%20is%3Aopen%20cycache On Saturday, September 10, 2016 at 5:36:53 PM UTC+2, leif wrote: > > Volker Braun wrote: > > There is cycache, but its currently disabled in Sage as we ran into so

[sage-devel] Re: PYTHONUSERBASE?

On the plus side, now that we don't sent LD_LIBRARY_PATH any more any extensions modules found in ~/.local actually have a chance of working. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

Re: [sage-devel] Re: PYTHONUSERBASE?

On Saturday, September 10, 2016 at 4:55:48 PM UTC+2, William wrote: > > Python itself could make those same arguments, as one can install > multiple copies of Python in different ways on a single computer. > Thats not really a valid argument, you are comparing apples and oranges. If anything, t

[sage-devel] Re: PYTHONUSERBASE?

I think this idea of installing stuff globally (either system-wide or in ~/.local) is outdated. Really its always better to make a venv if you need some sort of specialist package. Its just an all-around better workflow. And Sage-the-distribution really is like a big venv. I'd rather spend 5 s

Re: [sage-devel] sage -br rebuilds things that were not changed

Thats ok for reviewing tickets, and implemented as "git trac try ". But if you want to actually make changes then this creates a new merge commit which furthermore is against the conventional order (where the feature branch is the first parent). So it makes the commit history harder to unders

Re: [sage-devel] sage -br rebuilds things that were not changed

There is cycache, but its currently disabled in Sage as we ran into some bugs. On Saturday, September 10, 2016 at 12:20:54 AM UTC+2, William wrote: > > On Fri, Sep 9, 2016 at 3:08 PM, Volker Braun > wrote: > > Whenever you switch to a branch with a different working

Re: [sage-devel] sage -br rebuilds things that were not changed

Whenever you switch to a branch with a different working set you change timestamps of modified files. Git does not track timestamps. Updated timestamps cause recompilation. On Saturday, September 10, 2016 at 12:03:36 AM UTC+2, Paul Masson wrote: > > A little over a week ago I made a new branch

Re: [sage-devel] Jupyter notebook by default?

On Friday, September 9, 2016 at 2:53:29 PM UTC+2, kcrisman wrote: > > Sorry for the necropost, but I couldn't find any other canonical place to > mention this: > > htt

Re: [sage-devel] Re: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?

Go for it ;-) On Tuesday, August 30, 2016 at 12:22:07 PM UTC+2, Erik Bray wrote: > > On Tue, Aug 30, 2016 at 11:10 AM, Frédéric Chapoton > > wrote: > > Hello, > > > > May please somebody close all the 69 positive-reviewed > > duplicate/invalid/wontfix tickets ? > > > > if Volker has no time

[sage-devel] Re: Defining a doctest hook?

Just put the call to your cache cleaning function at the beginning of the docstring. Explicit is better than implicit. On Monday, August 29, 2016 at 1:42:45 PM UTC+2, Simon King wrote: > > Hi! > > Assume that you have a function that does some caching, and the doctests > will only work as exp

[sage-devel] Re: cohomology of topological spaces

On Monday, August 29, 2016 at 6:48:38 PM UTC+2, Travis Scrimshaw wrote: > > I believe "git trac checkout" is for retrieving a branch already on the > trac server. > It also creates a new one if there is none yet. The issue is somewhere in authentication, either the trac password is incorrect o

[sage-devel] Re: How to use Sage's doc builder off the source tree

On Sunday, August 28, 2016 at 2:30:27 PM UTC+2, Simon King wrote: > > Thus, the question remains: How to use the doc builder in order to > create in SAGE_ROOT/local/share/ the documentation of a pip-installable > module, Unless you plan on eventually putting the code in Sage I wouldn't use Sag

[sage-devel] Re: Iterators and KeyboardInterrupt

On Monday, August 22, 2016 at 8:27:28 PM UTC+2, Nils Bruin wrote: > > Iterators themselves are required to be "iterable", but in a strange way: > calling "iter" on an iterators gives you back an identical object! In > particular, if I is an iterator then calling next(I) and next(iter(I)) > shoul

[sage-devel] Re: Iterators and KeyboardInterrupt

On Monday, August 22, 2016 at 6:12:50 PM UTC+2, Nils Bruin wrote: > > Perhaps it's cleaner to hand out iterator objects that are kept track of > in the relevant loop. That iterator would then just die whenever the frames > of a KeyboardInterrupt exception are discarded and the flawed state > wou

[sage-devel] Re: Problem retrieving a (positively reviewed) ticket

This should be fixed now On Sunday, August 21, 2016 at 12:15:05 AM UTC+2, Emmanuel Charpentier wrote: > > I am finding myself unable to fetch the positively reviewed ticket > TRAC#21135 : > > charpent@asus16-ec:/usr/local/sage-7$ git trac checkout 21135 > Loading ticket #21135... > Checking out

[sage-devel] Re: daily WTF?

The many ways of implementing xor... Incidentally, if there is some global switch to return certificates instead of booleans then the sum version is the correct one ;-) On Saturday, August 20, 2016 at 11:51:42 AM UTC+2, William wrote: > > At Sage Days a new developer we're onboarding decided to

[sage-devel] Re: possibly controversial question: "Can I create commercial software using SageMath?"

On Saturday, August 20, 2016 at 2:28:58 AM UTC+2, Robert Dodier wrote: > > I know that various parties have offered their opinions about what > constitutes a derived work, including the FSF, the institution behind > the GPL. But even the FSF's interpretation isn't binding on anybody -- > whether

[sage-devel] Re: PlatformKeyboardEvent error in Sage notebook

Thats a chrome bug thats already fixed upstream... On Thursday, August 18, 2016 at 9:01:04 PM UTC+2, cir...@gmail.com wrote: > > When I have a Sage notebook in the browser, as I scroll up or down I > frequently see the following error on the console: > > [1:1:0818/131348:ERROR:PlatformKeyboardE

Re: [sage-devel] sage_mode for emacs has display problem in sage 7.4 beta0

PS: It would be easy enough to expose the simple-prompt either to the sage command line or have a special sage-embedded commandline entrypoint that starts witout any ANSI sequences. On Thursday, August 18, 2016 at 1:32:18 PM UTC+2, Volker Braun wrote: > > IMHO this is an intentional up

Re: [sage-devel] sage_mode for emacs has display problem in sage 7.4 beta0

IMHO this is an intentional upstream change and not a bug. So we'll have to either go with it or fork our own IPython. And I don't want to maintain an IPython fork. On Thursday, August 18, 2016 at 11:08:41 AM UTC+2, Martin R wrote: > > Since solving this appears to be tricky, is there a way to

[sage-devel] Re: Logging and optional tests

On Wednesday, August 17, 2016 at 9:44:45 PM UTC+2, Simon King wrote: > > "most logging messages are intended for reading by humans". And I believe > that a log is more easily accessible to humans if the log messages are > formatted so that logical blocks in the computation correspond to visual >

[sage-devel] Re: __repr__ in sage.interfaces.InterfaceElement called twice

I made https://trac.sagemath.org/ticket/21269 On Wednesday, August 17, 2016 at 10:04:47 AM UTC+2, Martin R wrote: > > While working on the new fricas interface, I noticed that the > method __repr__ in sage.interfaces.InterfaceElement is always called twice. > Apparently, once by __call__ in f

[sage-devel] Re: Logging and optional tests

I think thats hard to do because it runs against the grain for what logging is supposed to do. Usually we "log" the state of the program at a particular line of code, and not the previous execution history. In particular, one expects that only the order of log lines is switched if independent c

Re: [sage-devel] Build all optional pacakages

On Tuesday, August 16, 2016 at 2:07:43 PM UTC+2, Jeroen Demeyer wrote: > > There might be others too, like gdb on OS X doesn't work. > gdb on OSX should work, the only issue is that Apple decided that only root shall have sufficient permissions to use it (PTRACE) -- You received this message b

Re: [sage-devel] Re: git trac error

You need the newest git-trac version, presumably you checked out the repo somewhere. Find it and run "git pull (in the git-trac repo folder) On Sunday, August 14, 2016 at 10:51:36 PM UTC+2, Justin C. Walker wrote: > > > On Aug 14, 2016, at 13:44 , Dima Pasechnik wrote: > > > > > > > On Sunda

Re: [sage-devel] sage_mode for emacs has display problem in sage 7.4 beta0

Ipython 5 has now a comman-line switch "ipython --simple-prompt" that disables all escape sequences, but also disables prompt customizations. So instead of sage: its then always In[] / Out[]. I didn't find a way to turn of all ansi sequences while still changing the prompt to "sage:". On Sun

Re: [sage-devel] Re: checkout from trac

t it still > fails. > > I guess it's just not my day ... > > On 13 August 2016 at 16:13, Volker Braun > > wrote: > > You missed "git trac config" > > > > > wspage@sarah ~/sage $ git trac config --user bpage --pass 'xxx&

Re: [sage-devel] Re: checkout from trac

ce.py", line > 263, in _run > raise GitError(result) > git_trac.git_error.GitError: git returned with non-zero exit code > (128) when executing "git fetch trac /u/mantepse/21231" > STDERR: fatal: Invalid refspec '/u/mantepse/21231' > >

Re: [sage-devel] Re: checkout from trac

http://combinat.sagemath.org/doc/developer/git_trac.html In particular check out the sections on "Installing the Git-Trac Command" and then "Check out an Existing Ticket" On Saturday, August 13, 2016 at 6:55:10 PM UTC+2, Bill Page wrote: > > Sorry, I'm still confused. What exactly do I have to

[sage-devel] Re: Trac notifications again

On Friday, August 12, 2016 at 9:27:39 PM UTC+2, leif wrote: > > Only after reading the logs for 7.3 and 7.4.beta0 (and also by still > getting a specific doctest error in both) I realized that already for a > while positively reviewed tickets had *not* get merged... > Which ticket? -- You rec

[sage-devel] Re: broken %attach and %debug ?

Presumably attach (or, more generally, using the python inputhook) doesn't work since Ipython 5 now implements its own input handling. On Friday, August 12, 2016 at 2:22:51 PM UTC+2, Frédéric Chapoton wrote: > > is this only me, or the recent update to ipython 5.0 has broken severel > things

[sage-devel] Re: FriCAS installation fails

Yes, you need to update sage $ sage --package create -h usage: sage --package create [-h] [--version VERSION] [--tarball TARBALL] [--type TYPE] [package_name] positional arguments: package_name Package name. Default: fix all packag

[sage-devel] Re: increasing verbose level for sub-routines

The only good way is to rip out the "verbose" thing and replace it with the Python logging module. Then its easy to have different loggers for your code and for the flint interface, and make them log in different levels and/or different output streams. On Tuesday, August 9, 2016 at 11:42:32

Re: [sage-devel] Re: trac "diff" button

On Monday, August 8, 2016 at 10:13:25 AM UTC+2, Erik Bray wrote: > > This is the git repository browser that was cobbled on to Sage's Trac > because at some point or another the actual git plugin for Trac was > deemed insufficient I guess. Sage's Trac is the only one like this > that I know of.

[sage-devel] Re: Should warnings display a traceback?

Traceback in doctests are very minimal, they wouldn't really have more information than the warning. And really we shouldn't test where the warning is coming from (thats imho an implementation detail), only that there is a warning emitted. There is certainly a use case for getting a traceback f

[sage-devel] Re: doc.sagemath.org gone from google

Presumably Google decided that combinat is the canonical url, right? Hiding combinat is only kicking the problem down the road, there are presumably many copies of the Sage docs hosted somewhere. The correct solution would be to include a http://doc.sagemath.org/path/to/help.html"/> in our docs

[sage-devel] Re: How to share extern variables accross modules?

On Sunday, August 7, 2016 at 5:26:56 PM UTC+2, Simon King wrote: > > - My cohomology code (Python/Cython) cimports from sage.libs.modres, > sage.libs.meataxe and sage.matrix.matrix_gfpn_dense. > I build all these extension modules with >libraries = ['mtx', 'modres'] > in module_li

[sage-devel] Re: How to share extern variables accross modules?

On Sunday, August 7, 2016 at 3:04:18 PM UTC+2, Simon King wrote: > > OK, then I'll open a ticket to let the meataxe package provide a shared > library. My to-be-newstylified cohomology package relies on C library > that is created with -lmtx. That would work, but its probably a better design t

[sage-devel] Re: How to share extern variables accross modules?

On Sunday, August 7, 2016 at 12:12:51 PM UTC+2, Simon King wrote: > > Now I am puzzled. By "link to the same extension module", you mean that > all my modules should do >from sage.libs.meataxe cimport * > and then all should be fine? But they do so and it is *not* fine! The relevant crite

[sage-devel] Re: How to share extern variables accross modules?

st be a shared library. On Sunday, August 7, 2016 at 10:01:00 AM UTC+2, Simon King wrote: > > Hi Volker, > > On 2016-08-06, Volker Braun > wrote: > > On the C level both is possible; The header can declare it e.g. static, > > then every compilation unit gets it

[sage-devel] Re: How to share extern variables accross modules?

Thats really a C-level question, the different modules will see the same value iff the address of MtxLibDir is the same. On the C level both is possible; The header can declare it e.g. static, then every compilation unit gets its own copy. Or it can declare it extern, then it will be shared acr

Re: [sage-devel] Re: trac "diff" button

On Saturday, August 6, 2016 at 5:46:34 PM UTC+2, William wrote: > > Thanks -- in this case that is perfect, and often that will be all > that is needed. Is there any chance we could add a link to provide > &id2=develop, since it's a little hard to remember...? Whats the problem with clicking

Re: [sage-devel] Re: trac "diff" button

On Saturday, August 6, 2016 at 2:28:40 PM UTC+2, Johan S. R. Nielsen wrote: > > We are informally and without tools abiding by the ticket-DAG. Because there is no ticket-DAG and there is no immutable history of tickets. Ticket dependencies are informational but don't change what code is being a

Re: [sage-devel] Re: trac "diff" button

On Saturday, August 6, 2016 at 1:12:50 PM UTC+2, Johan S. R. Nielsen wrote: > > Yes, that's the way Git works. But should it really be the way our > ticket system should work? > You are trying to build a DAG of tickets that is a coarser version of the git DAG. You'd need * Tools to make sure

Re: [sage-devel] Re: trac "diff" button

On Saturday, August 6, 2016 at 12:37:59 PM UTC+2, Johan S. R. Nielsen wrote: > > Say #B is dependent on #A. If #A changes so #B no longer applies on top > of #A, ... Changing the branch on A doesn't change the branch on B. E.g. assume A, B started on the develop branch. Then commit on A, merge

Re: [sage-devel] Re: trac "diff" button

On Saturday, August 6, 2016 at 11:19:03 AM UTC+2, Johan S. R. Nielsen wrote: > > It would be really useful if the dependencies were filtered out as well. No, because dependencies are not static. You can e.g. delete the branch from a dependency after the dependent ticket has been reviewed... --

[sage-devel] Re: trac "diff" button

Since cgit doesn't know when you want the diff to start it can't really display anything more useful. You can add e.g. &id2=develop to the URL to specify the starting point, e.g. https://git.sagemath.org/sage.git/diff/?h=e5fc48064b490ac4e4bdc432885b38c0eaea3e27&id2=develop Though really you wan

[sage-devel] Re: Ethical evaluation of repository hosting services

On Wednesday, August 3, 2016 at 2:57:31 PM UTC+2, Dima Pasechnik wrote: > > How much is blocked by China's firewalls? > Afaik nothing on github is blocked in china: * Github is too important for commerce to be blocked for more than a couple of days at a time * Github uses https everywhere * You c

Re: [sage-devel] Issues when building Sage with --with-mp=gmp

Presumably thats https://trac.sagemath.org/ticket/15585 On Sunday, July 31, 2016 at 9:57:46 AM UTC+2, François wrote: > > What’s the failure with simplicial_complex.py? > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Re: Unify keywords certificate and certify

That just illustrates my point that its a bad api choice; Without consulting the docs its impossible to know if and what a certificate is going to mean. And if one has to look into the docs anyways then we could just point users at a better-named other method that computes said quantity. --

[sage-devel] Re: Unify keywords certificate and certify

On Friday, July 29, 2016 at 8:25:53 PM UTC+2, leif wrote: > > Even worse then, since it is meant to be the (imperative form of the) > /verb/. (Out of context, I'd assume the function takes an object of > some Certificate class, not a Boolean.) > Really its a variable (keyword argument), so ver

[sage-devel] Re: Unify keywords certificate and certify

On Friday, July 29, 2016 at 6:58:20 PM UTC+2, leif wrote: > > Well, while "certificate" is ambiguous (as it can be a verb as well as a > noun), While technically true, "certificate" is not commonly used as a verb. I don't think anybody would misguess noun vs verb here. Also I think it is the

[sage-devel] Re: So...who are the Singular experts?

One of the buildbots is building with SAGE_DEBUG=yes On Thursday, July 28, 2016 at 5:52:43 PM UTC+2, Nils Bruin wrote: > > With a little luck you can get all this by just setting SAGE_DEBUG=yes > when you build singular, but I'd expect that it has bitrotted by now and > would need some loving a

[sage-devel] Re: No longer able to build 7.2 or 7.3 betas on Mac OS X El Capitan

You tried the ipython 5.0 ticket, I presume. This left an empty directory lying around. Git doesn't know about empty directories, but our build system assumes that it is a package. And then fails and writes an incomplete makefile. You need to delete build/pkgs/prompt_toolkit, either by hand or

[sage-devel] please review #20802

Now would be a good time to review the one blocker that I fixed: https://trac.sagemath.org/ticket/20802 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel

Re: [sage-devel] Sage on Bash on Ubuntu on Windows

On Tuesday, July 26, 2016 at 1:25:34 PM UTC+2, Erik Bray wrote: > > 2) Currently this feature is intended as a developer tool only; On the plus side every user who is interested in Sage will immensely benefit from the scientific software universe that opens up by installing the ubuntu-on-windo

Re: [sage-devel] Re: survey ==> Python3

A language that did not change in the last 20 years is dead, plain and simple. Lets just look at strings, which is also one of the reasons driving the breaking change between Python 2 and 3. Back in the 90's it was ok to just take them as arrays of C chars. But nowadays you'd be totally crazy t

[sage-devel] Re: Trac attachment limit

Please don't attach binaries to trac; Everything that is attached becomes forever part of the trac database. Which is already in the multi-gigabyte range IIRC. On Monday, July 25, 2016 at 12:43:28 AM UTC+2, Andrey Novoseltsev wrote: > > Is there any deep reason to 2MB attachment limit on Trac?

<    1   2   3   4   5   6   7   8   9   10   >