On Sat, 26 Sep 2015, Tom Boothby wrote:
Hold on, why do you want to rule out zero? It seems like a dumb thing
to do a search at depth zero, but raising an error rather than
returning a trivial result is infuriating to a user.
I am not doing that. At first post I asked for functions to check
I've just tagged Nemo-0.3.1. This fixes some issues on OSX and on 32 bit
platforms that were reported. Other platforms are not affected.
Note that on OSX we don't provide binaries, but build from source. So you
need a working build environment (a fairly recent Xcode -- is that the
right incantatio
Hold on, why do you want to rule out zero? It seems like a dumb thing
to do a search at depth zero, but raising an error rather than
returning a trivial result is infuriating to a user.
On Sat, Sep 26, 2015 at 11:06 AM, John H Palmieri
wrote:
>
>
> On Saturday, September 26, 2015 at 10:55:57 AM
On Saturday, September 26, 2015 at 10:55:57 AM UTC-7, Jori Mäntysalo wrote:
>
> On Sat, 26 Sep 2015, Travis Scrimshaw wrote:
>
> > I would use:
> >
> > if n not in ZZ:
> >raise ValueError(...)
>
> Seems easy. But to make sure: does this work in all cases? I.e. raw Python
> ints, Sage In
On Sat, 26 Sep 2015, Travis Scrimshaw wrote:
I would use:
if n not in ZZ:
raise ValueError(...)
Seems easy. But to make sure: does this work in all cases? I.e. raw Python
ints, Sage Integers, maybe something else too? At least QQ(3) in NN seems
to work.
How about positive integers? "n-
I would use:
if n not in ZZ:
raise ValueError(...)
Best,
Travis
On Saturday, September 26, 2015 at 12:35:05 PM UTC-5, Jori Mäntysalo wrote:
>
> An example:
>
> sage: g = Graph({0:[1,2]})
> sage: list(g.breadth_first_search(0, distance='junk'))
> [0, 1, 2]
>
> This can be corrected: try:
An example:
sage: g = Graph({0:[1,2]})
sage: list(g.breadth_first_search(0, distance='junk'))
[0, 1, 2]
This can be corrected: try: n = Integer(...) ... if n<0: raise...
But it seems stupid to mechanically copy this code. So should we add
something like _check_integer_all(), _check_integer_non
> TLDR: Don't install OSX 10.11 if you want to use Sage
>
>
This should probably be prominently mentioned somewhere on the download
pages...
> OSX 10.11 disabled DYLD_* variables for scripts, more precisely: If a
> script file begins with a shebang the DYLD_* environment variables are
> om
>
> Post the Sage_crash_report.txt
> (Sage 6.9rc0 with xcode 7 under macosx 10.11)
>
Here it is:
***
IPython post-mortem report
{'commit_hash': u'2f7c727',
'commit_source': 'installation',
'default_encoding': 'UTF-8',
TLDR: Don't install OSX 10.11 if you want to use Sage
OSX 10.11 disabled DYLD_* variables for scripts, more precisely: If a
script file begins with a shebang the DYLD_* environment variables are
omitted from the set of environment variables passed to that interpreter.
So that fundamentally kill
Post the Sage_crash_report.txt
On Saturday, September 26, 2015 at 11:50:15 AM UTC+2, Juan Luis Varona
wrote:
>
> Unfortunately, the compiling process of sage 6.9rc0 with xcode 7 under
> macosx 10.11 has finished with errors:
>
> —
>
> ---
Unfortunately, the compiling process of sage 6.9rc0 with xcode 7 under macosx
10.11 has finished with errors:
—
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compile
>
> The question is if we should call it is().
>
Impossible because it is a Python keyword.
So, lacking a better proposal I'll stick to holds()
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving e
13 matches
Mail list logo
