Not that Sage will likely get some of this, but worth pointing out.
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubs
On Tuesday, April 29, 2014 3:56:10 PM UTC-4, Volker Braun wrote:
>
> Ok, I changed it to:
>
> $ git trac find b42c581
> Commit has been merged in 6.2.beta8. <- new
> addition
>
Yes, thanks! That will help a lot down the way.
Though Merged in is still a useful field
Hi,
Pickling of permutation groups is broken, and has been broken for a
while:
sage: G = PermutationGroup([[(1,2,3),(4,5)],[(3,4)]])
sage: G.category()
Category of finite permutation groups
sage: H = loads(dumps(G))
sage: H.category()
Category of sets
Analysis: th
I think you half-built Sage gcc conflicts with Apple gcc. Just "rm
-rf /usr/local/src/sage/local" and try again.
On Wednesday, April 30, 2014 10:56:11 PM UTC+1, Andrew wrote:
>
> On Thursday, 1 May 2014 00:47:20 UTC+10, Volker Braun wrote:
>>
>> Or just do a "git pull", since you are on the mas
On Thursday, 1 May 2014 00:47:20 UTC+10, Volker Braun wrote:
>
> Or just do a "git pull", since you are on the master branch this will give
> you 6.1.1 which afaik also builds on OSX 10.9.
>
As detailed above, I have the latest master branch but for some reason it
has the wrong version of singul
It appears git changed its output with some version <=1.9.2:
sage -t --long src/sage/dev/sagedev.py
**
File "src/sage/dev/sagedev.py", line 897, in
sage.dev.sagedev.SageDev.checkout_branch
Failed example:
dev.git.echo.stash('a
Or just do a "git pull", since you are on the master branch this will give
you 6.1.1 which afaik also builds on OSX 10.9.
On Wednesday, April 30, 2014 3:38:29 PM UTC+1, Jean-Pierre Flori wrote:
>
> To get the latest betas you should be tracking the "develop" branch (from
> trac or github, they
> No offense at all.
Oh, none taken at all ! I just wanted to emphasize that working for a
long time with Python and with Sage did not necessarily help.
> I was mainly referring to the __foo__ vs. _foo_ part,
> where (I think) once you've read why they're both there, it's not necessary
> to resta
To get the latest betas you should be tracking the "develop" branch (from
trac or github, they are the same).
You can issue something like:
"""
git checkout -b develop trac/develop
"""
to make a local copy of it and directly swith to it.
On Wednesday, April 30, 2014 4:30:44 PM UTC+2, Andrew wrote
OK, so the singular version seems to be in
$SAGE_ROOT/build/pkgs/singular/package-version.txt
and it is indeed set to 3.1.5.p9. Updating this by hand to 3.1.6.p1 and
then re-making gave a checksum error on
upstream/singular-3.1.6.p1
Deleting this and then re-making still gives a checksum erro
On Wednesday, 30 April 2014 20:48:01 UTC+10, Volker Braun wrote:
>
> On Wednesday, April 30, 2014 9:50:27 AM UTC+1, Andrew wrote:
>>
>> singular-3.1.5.p9
>>>
>>
> Sage-6.2.rc0 uses Singular 3.1.6.p1, you are building an old branch
> (possibly older than when we fixed the OSX 10.9 build). Are you
On Wed, Apr 30, 2014 at 9:31 AM, Ralf Stephan wrote:
> patchbot/patchbot.py", line 295, in check_base
> do_or_die("git fetch %s +%s:patchbot/base_upstream" %
>
(self.config['base_repo'], self.config['base_branch']))
>
Since I couldn't get a git version that worked (reinstalled curl and git
Great, it works!
Thanks a lot for the help.
Best,
Oskar
On Wednesday, April 30, 2014 3:24:34 PM UTC+2, Volker Braun wrote:
>
> Lower case. Open a terminal and run "sage -i topcom" (or
> "/Applications/sage/sage -i topcom" if it isn't in the search path).
>
>
>
>
> On Wednesday, April 30, 2
> And we shouldn't make (especially *private*) function names too verbose
> just for newbies, not just because they'd get more tedious
> to type, but also because code would get *harder* to read because of its
> length (or width).
1) I have been developping in Python/Sage for the last 4/5 years
Lower case. Open a terminal and run "sage -i topcom" (or
"/Applications/sage/sage -i topcom" if it isn't in the search path).
On Wednesday, April 30, 2014 2:12:34 PM UTC+1, Oskar Till wrote:
>
> Hi Guys,
>
> thanks for the support. However, I don't know where I'm supposed to type
> 'sage -i
Hi Guys,
thanks for the support. However, I don't know where I'm supposed to type
'sage -i topcom' ? is this the same as "sage: -i topcom", or the command
"sage: install_package('TOPCOM') " ?
I have the latest version installed, i.e 6.1.1 for mac OS.
When I type sage: install_package('TOPCOM'
On Wed, Apr 30, 2014 at 10:05 AM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
> How recent is your git?
>
/scratch/sage-6.1.1-x86_64-Linux$ ./local/bin/git --version
git version 1.8.4.4
/scratch/sage-6.1.1-x86_64-Linux$ git --version
git version 1.9.1
--
You received this message be
> Nor mine in the case of coercion and the _..._ methods :-) Because I
> already spent a lot of time on some pieces of the Sage infrastructure
> does not mean I (or anybody on sage-combinat-devel) am responsible for
> all of it. Which is why I suggested to report and make your case on
> sage-devel.
> Well, of course one needs to learn the language and its *context* if one
> wants to program something.
Yes, but we want to make the language easy to work with, and easy to learn.
_add_coerced_elements_ (if it makes any sense, I do not really know what
its ideal name should be) is clearly more in
On Wednesday, April 30, 2014 9:50:27 AM UTC+1, Andrew wrote:
>
> singular-3.1.5.p9
>>
>
Sage-6.2.rc0 uses Singular 3.1.6.p1, you are building an old branch
(possibly older than when we fixed the OSX 10.9 build). Are you sure you
didn't accidentally check out 6.2.beta0? Check "git log"
--
You
On Wed, Apr 30, 2014 at 12:19:41PM +0200, Nathann Cohen wrote:
>Not my job.
Nor mine in the case of coercion and the _..._ methods :-) Because I
already spent a lot of time on some pieces of the Sage infrastructure
does not mean I (or anybody on sage-combinat-devel) am responsible for
all of i
Hi Nathann,
["Followup-To:" nach gmane.comp.mathematics.sage.combinat.devel gesetzt.]
> There is also the problem of these __add__ and _add_. From just looking at
> the names you have no idea what the difference is, except if you wrote the
> code yourself.
Well, of course one needs to learn the l
On Wed, Apr 30, 2014 at 12:22:41PM +0200, Nathann Cohen wrote:
> Okay... Then would it make sense to make things like
> FiniteEnumeratedSet behave "as if they were real parents", for
> instance by implementing the __call__ function manually (or let it be
> inherited from Facade or whatever it is) s
Yo !
> Yup. We would want to properly support facade FiniteEnumeratedSets
> over plain Python objects and in particular have:
>
> sage: F = FiniteEnumeratedSet(["a","b","c"])
> sage: F("a")
> "a"
>
> However the coercion system currently does not support facades over
> plai
> My point was not about the existence of the answer, but the way I
> wrote it :-) Was it helpful?
Oh. As an answer on sage-devel yes, but you can' t write ling things like
that in the doc. I mean, if you do people probably will not find it when
they have the problem.
> This is about the coercion
On Wed, Apr 30, 2014 at 09:23:41AM +0200, Vincent Delecroix wrote:
> FiniteEnumeratedSet is aimed to not modify the input it gets. So if
> you feed it with Python objects which are not elements it will not
> complain and you have to go with that.
Yup. We would want to properly support facade Finit
On Wed, Apr 30, 2014 at 08:12:33AM +0200, Nathann Cohen wrote:
>Well, if you find the question justified, of course the answer should be
>in the doc.
My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?
>There is also the problem of these __ad
John H Palmieri wrote:
On Tuesday, April 29, 2014 6:20:25 PM UTC-7, John H Palmieri wrote:
On Tuesday, April 29, 2014 4:45:35 PM UTC-7, leif wrote:
leif wrote:
> Volker Braun wrote:
>> there is no separate spkg in sage >= 6, its is an optional
pkg but lives
On 30 April 2014 10:13, Jean-Pierre Flori wrote:
>
>
> On Wednesday, April 30, 2014 11:04:06 AM UTC+2, John Cremona wrote:
>>
>> On 30 April 2014 09:35, Jean-Pierre Flori wrote:
>> >
>> >
>> > On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet
>> > wrote:
>> >>
>> >> Hi all,
>> >>
On 30 April 2014 10:09, François Colas wrote:
> What I am trying to do is to use the prime factorisation of m to compute in
> another field than Q(zeta_m) (i.e. Q(zeta_m1, zeta_m2, ..., zeta_ml)) or
> Q[x]/ (i.e. Q[x1, ..., xl] / ) because I need m
> between 1000 and 1 and actually sage is not
On Wednesday, April 30, 2014 11:04:06 AM UTC+2, John Cremona wrote:
>
> On 30 April 2014 09:35, Jean-Pierre Flori >
> wrote:
> >
> >
> > On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet
> wrote:
> >>
> >> Hi all,
> >>
> >> I just noticed that we carefully check that Sag
What I am trying to do is to use the prime factorisation of m to compute in
another field than Q(zeta_m) (i.e. Q(zeta_m1, zeta_m2, ..., zeta_ml)) or
Q[x]/ (i.e. Q[x1, ..., xl] / ) because I need m
between 1000 and 1 and actually sage is not able to do this. The idea
is to have a faster arit
On 30 April 2014 09:35, Jean-Pierre Flori wrote:
>
>
> On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet wrote:
>>
>> Hi all,
>>
>> I just noticed that we carefully check that Sage computes something
>> completely wrong. From sage/structure/element.pyx, line 2052 :
>>
>> -
On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet wrote:
>
> Hi all,
>
> I just noticed that we carefully check that Sage computes something
> completely wrong. From sage/structure/element.pyx, line 2052 :
>
> --
> When little is implemented abou
Homebrew/Macports/Fink/etc are not supported and likely to conflict with
Sage. What kind of error do you get from "make distclean"? You can try to
exclude non-system stuff from the PATH to ignore 3rd party software:
export PATH=/usr/bin:/bin:/usr/sbin:/sbin
make distclean
make
On Wednesday, Ap
On 29 April 2014 19:23, Martin Albrecht wrote:
> On Monday 28 Apr 2014 14:57:59 François Colas wrote:
>> Hi Martin,
>>
>> Here is two examples using multivariate quotients and extension fields
>> which should be faster than computing CyclotomicField(m) or
>> NumberField(cyclotomic(m), 'r') :
>>
>>
How recent is your git?
On Wed, Apr 30, 2014 at 12:31 AM, Ralf Stephan wrote:
> OK, after fixing the self.log patchbot problem in patchbot-2.1.1 I get:
> Getting trusted author list...
> WARNING: Do not use this copy of sage while the patchbot is running.
> '/scratch/sage-6.1.1-x86_64-Linux'/sage
>
> This is one very special case where the Parent/Element relation is
> broken. First of all FiniteEnumeratedSet is not the parent of its
> elements (it is a facade):
>
Well, then I am asking whether it is a good idea / should be allowed.
We already have a tool to store list of elements with
On Wednesday, 30 April 2014 16:12:33 UTC+10, Nathann Cohen wrote:
>
> There is also the problem of these __add__ and _add_. From just looking at
> the names you have no idea what the difference is, except if you wrote the
> code yourself.
>
> Now, in the graph classes we have function like add_
OK, after fixing the self.log patchbot problem in patchbot-2.1.1 I get:
Getting trusted author list...
WARNING: Do not use this copy of sage while the patchbot is running.
'/scratch/sage-6.1.1-x86_64-Linux'/sage -i ccache
git checkout patchbot/base
git checkout -b patchbot/base
git fetch https://gi
Hi Nathann,
This is one very special case where the Parent/Element relation is
broken. First of all FiniteEnumeratedSet is not the parent of its
elements (it is a facade):
sage: F = FiniteEnumeratedSet([1, Partition([2,1]), Permutation([3,2,1])])
sage: F
{1, [2, 1], [3, 2, 1]}
sage: F[0].parent()
Hell everybody !
Here is the problem I met today:
sage: F = FiniteEnumeratedSet(("a","b","c")); F
{'a', 'b', 'c'}
sage: isinstance(F,Parent)
True
sage: F[0]
'a'
sage: F[0].parent()
---
AttributeError
42 matches
Mail list logo
