Re: [sage-devel] Sage + Hadoop

[Florent Hivert]

  Hi,

> I’m in the ‘big data’ practice at Accenture and am also a big fan of
> Sagemath, using it almost daily.  I’ve recently started wondering what
> interest you and the community would have in integrating Sagemath a
> bit with Hadoop or another map-reduce framework so that operations
> written in Sage could be shipped off to a running cluster for some
> distributed computation, along with being able to run Sage on much
> larger datasets than would fit on a single host.
> 
> There are some existing solutions which are clients to Hadoop’s map-
> reduce framework, such as Hive, which provides a pretty standard SQL-
> like front-end to a live cluster, that made me wonder if there’s not a
> way to extend the usefulness of Sagemath in a similar way.
> 
> I'd love to hear what interest there was in this idea.

I'm interested. But in the practical application I've in mind, the data isn't
there it is generated on the fly by sage itself. The problem it to gather
information (eg: the size) on huge sets from combinatorics. Those sets are
generated by a choice tree. The exploration of the various branches can
obviously be made in parallel.

If you want more information on the problem you can have a look at the
SearchForest [1]. I student made a prototype which can be found at [2].

Cheers,

Florent


[1] http://combinat.sagemath.org/doc/reference/sage/combinat/backtrack.html
[2] http://combinat.sagemath.org/patches/file/931c5a1e58bd/SFparalell-fh.patch

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: integration bug, segfault

[Dan Drake]

On Tue, 21 Feb 2012 at 09:44PM -0500, D. S. McNeil wrote:
> > I think it's very appropriate to open a ticket for this.  It would be
> > even more appropriate to try to construct a more minimal
> > counterexample :) but at least then we have it on the record.
> 
> So far the best I can do is
> 
> f(t) = e^(-(4.007 - 3*I)*t)
> integral(f, (t, 0, infinity))
> 
> *boom*
> 
> and note that 4007/1000 doesn't crash.

The problems here remind me a bit of what I came across in December:
https://groups.google.com/d/topic/sage-devel/JZ54xk51F-E/discussion

I didn't get a segfault, but in both cases, integrating with floats is
related to the problem.

Dan

--
---  Dan Drake
-  http://mathsci.kaist.ac.kr/~drake
---


signature.asc
Description: Digital signature

Re: [sage-devel] Sage + Hadoop

[Iftikhar Burhanuddin]

+1

On Wed, Feb 22, 2012 at 2:52 AM, akm  wrote:
> Dear Group,
>
> I’m in the ‘big data’ practice at Accenture and am also a big fan of
> Sagemath, using it almost daily.  I’ve recently started wondering what
> interest you and the community would have in integrating Sagemath a
> bit with Hadoop or another map-reduce framework so that operations
> written in Sage could be shipped off to a running cluster for some
> distributed computation, along with being able to run Sage on much
> larger datasets than would fit on a single host.
>
> There are some existing solutions which are clients to Hadoop’s map-
> reduce framework, such as Hive, which provides a pretty standard SQL-
> like front-end to a live cluster, that made me wonder if there’s not a
> way to extend the usefulness of Sagemath in a similar way.
>
> I'd love to hear what interest there was in this idea.
>
> Best
> Andrew
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Re: A_tour_of_sage_Zh

[Minh Nguyen]

Hi,

On Sat, Feb 18, 2012 at 10:56 PM, 廖祥  wrote:
> Thanks to reply my message , and your constructive advises . I just have
> modified the document according to your suggestions , now this .rar file
> include the LaTeX source .
> In fact , if my translation can be release with Sage Official Doc , I'll
> update it  once a new sage version is released  , and add more examples .
> Recently , i put all my spare time (limited , but always have a little) into
> a chinese book about sage , that means i will translate more sage document
> into chinese . I even want to create a project to call more sage's chinese
> supporters to do this work on GoogleCode .
> Who told sage is so fascinating (maybe not native speaking)?  I just love it
> very much !

Thank you very much for your attachment.  I have made a Trac ticket
[1] in order to get into the Sage documentation your Chinese
translation of the document "A tour of Sage".  You should be notified
of any changes to the ticket.  To get your document into the Sage
standard documentation, the work that needs to be done now include:

* Convert your LaTeX file to Sphinx format.

* Get another person fluent in Chinese to review your document.

Once again, I want to thank you for your work.

[1] http://trac.sagemath.org/sage_trac/ticket/12559

-- 
Regards,
Minh Van Nguyen
http://sage.math.washington.edu/home/mvngu/

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] AMS Mathematics Research Community on Arithmetic Statistics (=number theory) to be held June 24-30 in Snowbird, Utah.

[William Stein]

Dear Young Number Theoretic Sage-Developers,

I'm co-organizing (with Brian Conrey, Chantal David, Wei Ho, Nina
Snaith, and Mike Rubinstein) an AMS Mathematics Research Community on
Arithmetic Statistics (=number theory) to be held June 24-30 in Snowbird, Utah.

Applications are due by **March 1**. We're looking for postdocs and
advanced grad students.  Most spots are reserved for U.S. citizens
as well as to those who are affiliated with U.S. institutions. But there are
a few spots for non-US citizens.

More info, including how to apply, is here:

http://www.ams.org/programs/research-communities/mrc-12

(scroll to the bottom for instructions on applying. Deadline is March 1).

Thanks,

 William

-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: sage-5.0.x and OS X 10.7 Lion

[Robert Bradshaw]

On Fri, Feb 3, 2012 at 11:31 PM, David Roe  wrote:
>> As for why your viewpoint might be harmful: I have heard anecdotes of
>> people
>> not wanting to release their code because it was ugly, or nonstandard, or
>> difficult to use, etc. As long as the response that they are going to
>> receive
>> it along the lines of the above, that viewpoint is valid, even if the
>> response
>> should be "Yes, this is ugly, but it is still awesome."
>>
>> Large (most?) parts of Sage have simply come from third-party code written
>> by people who never had any intention of having anything to do with Sage.
>> Such people should be encouraged to release their code, not called idiots
>> when they do release it.
>
>
> +1

+1

I was having the exact same thoughts when reading this thread, and
this is not the first time. Sometimes it feels like I'm in a math
lecture and someone is complaining that it's no good because of the
poor penmanship. "Sheesh, he can't even properly cross his T's, and
will you look at that punctuation..." Perhaps that's a bit extreem,
but you get the point. It's not that there's not room for improvement
(there often is plenty), but that's not the primary consideration, if
it's a consideration at all for the original author. Even for those
that intend to write good code (which is most of the people I know),
experience, ignorance, or other constraints get in the way.

For someone who's profession is coding, a higher standard is more
reasonable, but I think we'd be waiting around a long time before
anyone wrote ratpoints if we wait for the "professionals." More
mathematicians know (a little) how to code than programmers know (a
little) algebraic geometry, and they have a lot to contribute.

- Robert

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: integration bug, segfault

[kcrisman]

On Feb 21, 9:44 pm, "D. S. McNeil"  wrote:
> > I think it's very appropriate to open a ticket for this.  It would be
> > even more appropriate to try to construct a more minimal
> > counterexample :) but at least then we have it on the record.
>
> So far the best I can do is
>
> f(t) = e^(-(4.007 - 3*I)*t)
> integral(f, (t, 0, infinity))
>
> *boom*
>
> and note that 4007/1000 doesn't crash.
>
> Primality of the numbers seems to correlate with crashing (possibly
> due to how Maxima handles floats?), and the ones that don't blow the

Yes, that whole "replacing by a rational" thing...

sage: maxima_calculus(" integrate(%e^(-(4.007-3*%i)*t),t,0,inf)")
.11973156661690758*%i+.15992146247798286

So somehow part of it must be the exact thing we are sending to ECL.

More details.

In Maxima 5.26.0:

(%i3) display2d:false;

(%o3) false
(%i4) integrate(%e^(-(4.007-3*%i)*t),t,0,inf);

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007
(%o4) (300*%i+4007000)/25056049

In our (older) one:

(%i1) display2d:false;

(%o1) false
(%i2) integrate(%e^(-(4.007-3*%i)*t),t,0,inf);

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -.1197315666169076 by -1463/12219 = -.1197315655945658

rat: replaced -.1599214624779829 by -2525/15789 = -.159921464310596

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -.1599214624779829 by -2525/15789 = -.159921464310596

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced .11973156661690758 by 1463/12219 = .11973156559456584

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -.1197315666169076 by -1463/12219 = -.1197315655945658

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -4.007 by -4007/1000 = -4.007

rat: replaced -.1599214624779829 by -2525/15789 = -.159921464310596
(%o2) .11973156661690758*%i+.15992146247798286

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: integration bug, segfault

[D. S. McNeil]

> I think it's very appropriate to open a ticket for this.  It would be
> even more appropriate to try to construct a more minimal
> counterexample :) but at least then we have it on the record.

So far the best I can do is

f(t) = e^(-(4.007 - 3*I)*t)
integral(f, (t, 0, infinity))

*boom*

and note that 4007/1000 doesn't crash.

Primality of the numbers seems to correlate with crashing (possibly
due to how Maxima handles floats?), and the ones that don't blow the
stack tend to ask "Is  125*I-167  positive, negative, or zero?" and
other dubious questions.


Doug

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: integration bug, segfault

[kcrisman]

On Feb 21, 8:38 pm, Jonathan Bober  wrote:
> I didn't actually expect the following to work very well, but I definitely
> did not expect the output that I did get:
>
> sage: def IC9E(K, j, a, b, epsilon):
> :     g(t) = 2*pi*i * (a - i*a + 2*b*K + i*2*b*K)*(1+i)*t - (1+i)^2 *
> 2*i*b*t^2
> :     f(t) = t^j * exp(g(t))
> :     return integral(f, (t, 0, infinity))
> sage: IC9E(112, 0, 0.00084696102822690023, 0.044171315635412135, exp(-20))
> # suddenly I get a lot of advertisements for a popular question/answer
> website...
> [...]
> ;;;
> ;;; Binding stack overflow.
> ;;; Jumping to the outermost toplevel prompt
> ;;;
> [...]
> ;;;
> ;;; Stack overflow.
> ;;; Jumping to the outermost toplevel prompt
> ;;;
> [...]
> /home/bober/sage-5.0.beta2/spkg/bin/sage: line 304:  3765 Segmentation
> fault      sage-ipython "$@" -i
>
> The [...] omits a lot of output (from maxima?). The above was on 5.0.beta2,
> but it happens at sagenb.org as well.
>
> I haven't opened a track ticket because I would prefer to put something
> more specific than the subject of this email. I guess that there is some
> sort of bug in maxima, maybe, but also maybe a bug in Sage, since (maybe)
> Sage shouldn't crash when the maxima subprocess crashes.

I think it's very appropriate to open a ticket for this.  It would be
even more appropriate to try to construct a more minimal
counterexample :) but at least then we have it on the record.

What role does epsilon play in the above, by the way?  I removed it
from the example without harm, unfortunately without changing the
horrible segfault.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] integration bug, segfault

[Jonathan Bober]

I didn't actually expect the following to work very well, but I definitely
did not expect the output that I did get:

sage: def IC9E(K, j, a, b, epsilon):
: g(t) = 2*pi*i * (a - i*a + 2*b*K + i*2*b*K)*(1+i)*t - (1+i)^2 *
2*i*b*t^2
: f(t) = t^j * exp(g(t))
: return integral(f, (t, 0, infinity))
sage: IC9E(112, 0, 0.00084696102822690023, 0.044171315635412135, exp(-20))
# suddenly I get a lot of advertisements for a popular question/answer
website...
[...]
;;;
;;; Binding stack overflow.
;;; Jumping to the outermost toplevel prompt
;;;
[...]
;;;
;;; Stack overflow.
;;; Jumping to the outermost toplevel prompt
;;;
[...]
/home/bober/sage-5.0.beta2/spkg/bin/sage: line 304:  3765 Segmentation
fault  sage-ipython "$@" -i

The [...] omits a lot of output (from maxima?). The above was on 5.0.beta2,
but it happens at sagenb.org as well.

I haven't opened a track ticket because I would prefer to put something
more specific than the subject of this email. I guess that there is some
sort of bug in maxima, maybe, but also maybe a bug in Sage, since (maybe)
Sage shouldn't crash when the maxima subprocess crashes.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Are the Sage binaries for OS X are crap?

[kcrisman]

On Feb 21, 6:20 pm, "Georg S. Weber" 
wrote:
> Hi all,
>
> I finally could verify that the patch at trac 12161 is good, i.e.
> heals not only the original problem for OS X 10.7, but the
> "_PyUnicodeUCS4_AsUTF8String" incarnation, too (at least on one of my
> own OS X 10.6 installations --- try starting a Sage "app" after
> (closing all Sage and all terminal sessions, and) nuking/
> removing .sage, *and* do so on a system that boots up in 64bit mode,
> i.e. by pressing "6" and "4" during startup --- but maybe the computer
> just has to be "young enough" so that the OS X 10.6/10.7 installs
> something different than on "older" ones, which would be 64bit
> capable, but Apple does boot them only in 32bit mode; 
> seehttp://support.apple.com/kb/HT3773and  http://support.apple.com/kb/HT3770).
>
> Anyway, would it make sense now to upload some official update of the
> OS X 10.6 app (with only the trac 12161 patch as delta to the original
> one currently in the download area)?

Unless 5.0 is coming within a week (and given the status of
http://trac.sagemath.org/sage_trac/ticket/12024 and
http://trac.sagemath.org/sage_trac/ticket/11881, that seems highly
unlikely), I think this is a VERY good idea.  As I've said before, my
own laptop has something weird with a missing libtiff or something, so
I am reluctant to do it, but hopefully anyone else could?  Or the
buildbot?

And if someone can make Sage 4.8 binaries for Intel 10.4 and 10.5,
that would be even better :)

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-5.0.x and OS X 10.7 Lion

[Justin C. Walker]

On Feb 21, 2012, at 16:57 , R. Andrew Ohana wrote:

> On Tue, Feb 21, 2012 at 15:37, Justin C. Walker  wrote:
>> 
>> On Feb 21, 2012, at 14:16 , R. Andrew Ohana wrote:
>> 
>>> On Tue, Feb 21, 2012 at 10:30, Justin C. Walker  wrote:
 
 On Feb 21, 2012, at 08:13 , R. Andrew Ohana wrote:
>> [snip]
> FYI, sqrt5 has been down for awhile since it is extremely prone to
> kernel panics and I have yet to figure out the issue. My guess at this
> point in time is that these are due to it using the 32-bit kernel,
> which apple clearly isn't supporting any more -- the main requirement
> of 10.8 over 10.7 is support for the 64-bit kernel.
 
 Is this true?
>>> 
>>> Positive:
>>> 
>>> $ uname -pr
>>> 11.3.0 i386
>>> 
  My 10.7 system has a 64-bit kernel, at least according to 'file':
 
 $ file /mach_kernel
 /mach_kernel: Mach-O universal binary with 2 architectures
 /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
 /mach_kernel (for architecture i386):   Mach-O executable i386
>>> 
>>> OSX has included extensions in the 32-bit kernel to execute 64-bit
>>> code since leopard (or potentially earlier), this only indicates that
>>> the kernel + hardware supports executing 64-bit code.
>> 
>> I don't think this is really correct.  This is what the Apple website says:
>> 
>> =
>> These Macs use the 64-bit kernel by default in Mac OS X v10.6.
>> 
>>• Mac Pro (Mid 2010)
>>• MacBook Pro (Early 2011)
>>• iMac (21.5-inch and 27-inch, Mid 2011)
>> =
> 
> Yes, although for lion it seems to be a much larger number of systems.

Not sure about that, but I don't know why that would be.

>> 
>> I'm running the MacBook Pro (Early 2011).  'uname -pr'

To be clear: I am running 10.7 on this MacBook.

> Looking at another system that has booted with the 64-bit kernel it
> seems that -p does not distinguish, but -m does:
> 
> sqrt5:~ uname -m
> i386
> 
> sage1:~ uname -m
> x86_64

Yeah; the "-p" is the ISP architecture (the machine "api"): i386 is the common 
ISP architecture for (most) Intel processors; "-m" is the hardware type (in my 
case: Core i7), x86_64.

> 'file /mach_kernel' matches on these two systems

That's because Apple ships a single (universal) kernel binary that is intended 
to work on all supported systems.

Cheers,

Justin

--
Justin C. Walker, Curmudgeon-at-Large
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email



-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-5.0.x and OS X 10.7 Lion

[R. Andrew Ohana]

On Tue, Feb 21, 2012 at 15:37, Justin C. Walker  wrote:
>
> On Feb 21, 2012, at 14:16 , R. Andrew Ohana wrote:
>
>> On Tue, Feb 21, 2012 at 10:30, Justin C. Walker  wrote:
>>>
>>> On Feb 21, 2012, at 08:13 , R. Andrew Ohana wrote:
> [snip]
 FYI, sqrt5 has been down for awhile since it is extremely prone to
 kernel panics and I have yet to figure out the issue. My guess at this
 point in time is that these are due to it using the 32-bit kernel,
 which apple clearly isn't supporting any more -- the main requirement
 of 10.8 over 10.7 is support for the 64-bit kernel.
>>>
>>> Is this true?
>>
>> Positive:
>>
>> $ uname -pr
>> 11.3.0 i386
>>
>>>  My 10.7 system has a 64-bit kernel, at least according to 'file':
>>>
>>> $ file /mach_kernel
>>> /mach_kernel: Mach-O universal binary with 2 architectures
>>> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
>>> /mach_kernel (for architecture i386):   Mach-O executable i386
>>
>> OSX has included extensions in the 32-bit kernel to execute 64-bit
>> code since leopard (or potentially earlier), this only indicates that
>> the kernel + hardware supports executing 64-bit code.
>
> I don't think this is really correct.  This is what the Apple website says:
>
> =
> These Macs use the 64-bit kernel by default in Mac OS X v10.6.
>
>        • Mac Pro (Mid 2010)
>        • MacBook Pro (Early 2011)
>        • iMac (21.5-inch and 27-inch, Mid 2011)
> =

Yes, although for lion it seems to be a much larger number of systems.
>
> I'm running the MacBook Pro (Early 2011).  'uname -pr'
Looking at another system that has booted with the 64-bit kernel it
seems that -p does not distinguish, but -m does:

sqrt5:~ uname -m
i386

sage1:~ uname -m
x86_64

'file /mach_kernel' matches on these two systems

> says what you report, but I think that is the "basic ISP" architecture, which 
> is, and I assume will be, i386.
>
> The kernel being  "x86_64" means that it actually runs in 64-bit mode.
>
> Justin
>
> --
> Justin C. Walker, Curmudgeon-At-Large
> Institute for the Absorption of Federal Funds
> 
> If you're not confused,
> You're not paying attention
> 
>
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



-- 
Andrew

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Sage works on OS X 10.7!

[John H Palmieri]

On Tuesday, February 21, 2012 2:00:01 PM UTC-8, entropy wrote:
>
> John, 
>
> Just to confirm, did this build work for you on Lion 10.7.2, with 
> Xcode 4.3, and gcc version 4.2.1 (LLVM build 2336.9.00)? 


I'm using Lion 10.7.3, not 10.7.2. I agree with the gcc version:

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.9.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Apple clang version 3.1 (tags/Apple/clang-318.0.45) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix

$ uname -a
Darwin Macintosh-001b639d44a1.local 11.3.0 Darwin Kernel Version 11.3.0: 
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64

(I get the same output, except for the machine name, on a desktop machine 
and on a laptop. For building sage-5.0.beta4-gcc.tar, with the previous 
version of Xcode, the desktop worked with either the default compiler or 
with clang, while with the laptop, I was only able to build using CC=clang 
and CXX=clang++.)
 

> From you 
> follow-up messages I am assuming that beta4-gcc still builds a copy of 
> gcc-4.6 on top of everything else, correct? 
>

Yes, absolutely. 


> I never was able to get clang to build sage on my Apple (10.7.2 with 
> Xcode 4.2). I was wondering if a few of you who were able to 
> successfully build sage on your Mac could chime in with your "uname - 
> a" as well as Xcode and gcc versions. I'm on 
>

With the same sage-5.0.beta4-gcc tarball, using CC=clang and CXX=clang++, 
gcc built just fine, and then it was used to build everything else.  I 
haven't had luck building a plain sage-5.0.beta4 tarball. 

-- 
John

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-5.0.x and OS X 10.7 Lion

[Justin C. Walker]

On Feb 21, 2012, at 14:16 , R. Andrew Ohana wrote:

> On Tue, Feb 21, 2012 at 10:30, Justin C. Walker  wrote:
>> 
>> On Feb 21, 2012, at 08:13 , R. Andrew Ohana wrote:
[snip]
>>> FYI, sqrt5 has been down for awhile since it is extremely prone to
>>> kernel panics and I have yet to figure out the issue. My guess at this
>>> point in time is that these are due to it using the 32-bit kernel,
>>> which apple clearly isn't supporting any more -- the main requirement
>>> of 10.8 over 10.7 is support for the 64-bit kernel.
>> 
>> Is this true?
> 
> Positive:
> 
> $ uname -pr
> 11.3.0 i386
> 
>>  My 10.7 system has a 64-bit kernel, at least according to 'file':
>> 
>> $ file /mach_kernel
>> /mach_kernel: Mach-O universal binary with 2 architectures
>> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
>> /mach_kernel (for architecture i386):   Mach-O executable i386
> 
> OSX has included extensions in the 32-bit kernel to execute 64-bit
> code since leopard (or potentially earlier), this only indicates that
> the kernel + hardware supports executing 64-bit code.

I don't think this is really correct.  This is what the Apple website says:

=
These Macs use the 64-bit kernel by default in Mac OS X v10.6.

• Mac Pro (Mid 2010)
• MacBook Pro (Early 2011)
• iMac (21.5-inch and 27-inch, Mid 2011)
=

I'm running the MacBook Pro (Early 2011).  'uname -pr' says what you report, 
but I think that is the "basic ISP" architecture, which is, and I assume will 
be, i386.

The kernel being  "x86_64" means that it actually runs in 64-bit mode.

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds

If you're not confused,
You're not paying attention




-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Keshav Kini]

Jason Grout  writes:

> On 2/21/12 12:19 PM, Robert Bradshaw wrote:
>> Perhaps we could require that every state
>> of the main line be consistant, and if it's worthwhile to preserve
>> inconsistent history we merge it as a branch rather than rebasing.
>
> That seems very reasonable to me.

+1. IMO, merging into master is a more "correct" way of squashing
multiple commits into one commit (the merge commit, from the point of
view of the main trunk), since you still have the original history.

Merging into the main line (the master branch) would be equivalent to
what right now we call getting your patch merged.

-Keshav


Join us in #sagemath on irc.freenode.net !

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Are the Sage binaries for OS X are crap?

[Georg S. Weber]

Hi all,

I finally could verify that the patch at trac 12161 is good, i.e.
heals not only the original problem for OS X 10.7, but the
"_PyUnicodeUCS4_AsUTF8String" incarnation, too (at least on one of my
own OS X 10.6 installations --- try starting a Sage "app" after
(closing all Sage and all terminal sessions, and) nuking/
removing .sage, *and* do so on a system that boots up in 64bit mode,
i.e. by pressing "6" and "4" during startup --- but maybe the computer
just has to be "young enough" so that the OS X 10.6/10.7 installs
something different than on "older" ones, which would be 64bit
capable, but Apple does boot them only in 32bit mode; see
http://support.apple.com/kb/HT3773 and  http://support.apple.com/kb/HT3770).

Anyway, would it make sense now to upload some official update of the
OS X 10.6 app (with only the trac 12161 patch as delta to the original
one currently in the download area)?


Cheers,
Georg

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Sage works on OS X 10.7!

[R. Andrew Ohana]

On Tue, Feb 21, 2012 at 14:00, entropy  wrote:
> John,
>
> Just to confirm, did this build work for you on Lion 10.7.2, with
> Xcode 4.3, and gcc version 4.2.1 (LLVM build 2336.9.00)? From you
> follow-up messages I am assuming that beta4-gcc still builds a copy of
> gcc-4.6 on top of everything else, correct?

Yup, this is correct.

>
> I never was able to get clang to build sage on my Apple (10.7.2 with
> Xcode 4.2).

Just to make sure, you were using the gcc version of sage, yes? There
are some components of sage that rely on gnu extensions, so currently
gcc is needed, however you should be able to build the bundled version
of gcc+deps with clang.

> I was wondering if a few of you who were able to
> successfully build sage on your Mac could chime in with your "uname -
> a" as well as Xcode and gcc versions. I'm on
>
> $ uname -a
> Darwin hyperion 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12
> 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
>
> with
> $ gcc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
> build 5658) (LLVM build 2335.15.00)
>
> and Xcode version 4.1.

Would you mind giving clang --version as well (I only tested on Xcode
4.2 and am currently testing with the freely released command line
tools that were released alongside 4.3).

>
> Thanks,
> Jesse
>
>
> On Feb 19, 12:53 am, John H Palmieri  wrote:
>> On Saturday, February 18, 2012 3:12:19 PM UTC-8, John H Palmieri wrote:
>>
>> > We have another small problem with Lion. I just wiped my hard drive and
>> > reinstalled Lion (because of some non-Sage related issues). Then I
>> > reinstalled Xcode: the newly released version 4.3.  Two issues:
>> > command-line tools are no longer installed by default, so you have to
>> > install gcc, clang, etc., by running Xcode, choosing "Preferences",
>> > clicking the "Downloads" tab, and installing "Command Line Tools".  Next,
>> > there is now no longer a /Developer directory, which means that the command
>> > xcodebuild (which is run by the prereq script) may fail to report the
>> > correct version of Xcode. So from the shell, you need to run
>>
>> >   $ xcode-select -switch /Applications/Xcode.app/Contents/Developer
>>
>> > (and you may need to run this via sudo).  So these instructions need to be
>> > added to the installation guide or the README.txt file.
>>
>> > For the second issue, it might instead be better to figure out the version
>> > of Xcode some other way in the prereq script (and anywhere else this is
>> > done, like maybe the current python spkg).
>>
>> > This version of Xcode has new versions of gcc and clang, so I'm trying to
>> > compile with those to see if it makes any difference.
>>
>> On the plus side, on the laptop where I had problems before, Sage built and
>> passed all doctests using the default compiler:
>>
>> $ gcc --version
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
>> 5658) (LLVM build 2336.9.00)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> I'm going to build with SAGE_CHECK=yes to see what packages fail
>> self-tests, but Apple seems to have fixed some of their compiler bugs in
>> this latest release.
>>
>> --
>> John
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



-- 
Andrew

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-5.0.x and OS X 10.7 Lion

[R. Andrew Ohana]

On Tue, Feb 21, 2012 at 10:30, Justin C. Walker  wrote:
>
> On Feb 21, 2012, at 08:13 , R. Andrew Ohana wrote:
>
>> On Tue, Feb 21, 2012 at 07:08, Dima Pasechnik  wrote:
>>> In gmane.comp.mathematics.sage.devel, you wrote:
 On Mon, Feb 20, 2012 at 4:28 AM, Dima Pasechnik  wrote:
> Can we get Lion on bsd.math.washington.edu ?

 I could, but then we will no longer have a 10.6 build/test machine, I
 think, and that would be bad.
 Also, I can't do this until next week, since I'm in San Diego right now.

>>> sure, I understand, but it seems that 10.7 is becoming a major hassle to
>>> support, and so having a machine running it available would really be
>>> great…
>
>> FYI, sqrt5 has been down for awhile since it is extremely prone to
>> kernel panics and I have yet to figure out the issue. My guess at this
>> point in time is that these are due to it using the 32-bit kernel,
>> which apple clearly isn't supporting any more -- the main requirement
>> of 10.8 over 10.7 is support for the 64-bit kernel.
>
> Is this true?

Positive:

$ uname -pr
11.3.0 i386

> My 10.7 system has a 64-bit kernel, at least according to 'file':
>
> $ file /mach_kernel
> /mach_kernel: Mach-O universal binary with 2 architectures
> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
> /mach_kernel (for architecture i386):   Mach-O executable i386

OSX has included extensions in the 32-bit kernel to execute 64-bit
code since leopard (or potentially earlier), this only indicates that
the kernel + hardware supports executing 64-bit code.

>
> Justin
>
> --
> Justin C. Walker
> Director
> Institute for the Enhancement of the Director's Income
> --
> Fame is fleeting, but obscurity
>   just drags on and on.      F&E
>
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



-- 
Andrew

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Sage works on OS X 10.7!

[entropy]

John,

Just to confirm, did this build work for you on Lion 10.7.2, with
Xcode 4.3, and gcc version 4.2.1 (LLVM build 2336.9.00)? From you
follow-up messages I am assuming that beta4-gcc still builds a copy of
gcc-4.6 on top of everything else, correct?

I never was able to get clang to build sage on my Apple (10.7.2 with
Xcode 4.2). I was wondering if a few of you who were able to
successfully build sage on your Mac could chime in with your "uname -
a" as well as Xcode and gcc versions. I'm on

$ uname -a
Darwin hyperion 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12
18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64

with
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2335.15.00)

and Xcode version 4.1.

Thanks,
Jesse


On Feb 19, 12:53 am, John H Palmieri  wrote:
> On Saturday, February 18, 2012 3:12:19 PM UTC-8, John H Palmieri wrote:
>
> > We have another small problem with Lion. I just wiped my hard drive and
> > reinstalled Lion (because of some non-Sage related issues). Then I
> > reinstalled Xcode: the newly released version 4.3.  Two issues:
> > command-line tools are no longer installed by default, so you have to
> > install gcc, clang, etc., by running Xcode, choosing "Preferences",
> > clicking the "Downloads" tab, and installing "Command Line Tools".  Next,
> > there is now no longer a /Developer directory, which means that the command
> > xcodebuild (which is run by the prereq script) may fail to report the
> > correct version of Xcode. So from the shell, you need to run
>
> >   $ xcode-select -switch /Applications/Xcode.app/Contents/Developer
>
> > (and you may need to run this via sudo).  So these instructions need to be
> > added to the installation guide or the README.txt file.
>
> > For the second issue, it might instead be better to figure out the version
> > of Xcode some other way in the prereq script (and anywhere else this is
> > done, like maybe the current python spkg).
>
> > This version of Xcode has new versions of gcc and clang, so I'm trying to
> > compile with those to see if it makes any difference.
>
> On the plus side, on the laptop where I had problems before, Sage built and
> passed all doctests using the default compiler:
>
> $ gcc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
> 5658) (LLVM build 2336.9.00)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I'm going to build with SAGE_CHECK=yes to see what packages fail
> self-tests, but Apple seems to have fixed some of their compiler bugs in
> this latest release.
>
> --
> John

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Sage + Hadoop

[akm]

Dear Group,

I’m in the ‘big data’ practice at Accenture and am also a big fan of
Sagemath, using it almost daily.  I’ve recently started wondering what
interest you and the community would have in integrating Sagemath a
bit with Hadoop or another map-reduce framework so that operations
written in Sage could be shipped off to a running cluster for some
distributed computation, along with being able to run Sage on much
larger datasets than would fit on a single host.

There are some existing solutions which are clients to Hadoop’s map-
reduce framework, such as Hive, which provides a pretty standard SQL-
like front-end to a live cluster, that made me wonder if there’s not a
way to extend the usefulness of Sagemath in a similar way.

I'd love to hear what interest there was in this idea.

Best
Andrew

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Fernando Perez]

On Tue, Feb 21, 2012 at 11:39 AM, Jason Grout
 wrote:
>
> Interesting.  Where is this assignee field?  Is it the assignee field in the
> Issues?  Does setting that require that the committer be the assignee?

It's in the gray bar below the title for the PR.  Anyone in the team
who owns the target repo can be assignee, it's a drop-list that shows
all the committers to the target repo.

Cheers,

f

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Fernando Perez]

On Tue, Feb 21, 2012 at 12:32 PM, Robert Bradshaw
 wrote:
>
>> No, you can keep pushing to the branch you created the PR from, and
>> new commits show up as they are made.  You can even rebase and force
>> push, and the PR will get rebased too.  We do the first all the time,
>> and the second also, though less frequently.
>
> What happens to (inline) comments in this case?

I think they get preserved as static snippets in the discussion page,
but I'm not 100% sure.  I know we have PRs that have gone through
this, but I wouldn't know how to find one right now to verify; if
you're really curious we could do a quick experiment with a fake PR to
test what happens, it would not take long.

Cheers,

f

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Robert Bradshaw]

On Tue, Feb 21, 2012 at 11:17 AM, Fernando Perez  wrote:
> On Tue, Feb 21, 2012 at 11:03 AM, Christopher Swenson
>  wrote:
>> My only possible issue with the github workflow: I'm not sure how it
>> interacts with having multiple people who have control of the "master"
>> (central) repo. When a pull request comes in, can anyone who has push access
>> to the repo take control of that pull request?
>
> Yes.  Typically one or more core committers participate in the
> discussion, and it's easy to informally choose who does the final
> merge.  But if you want to be more formal about it, there's an
> assignee field and a project can choose to use it explicitly and
> require that person to be the one who does the actual final merge.

I think we'd still keep our code review process, and the release
manager would to the actual merge, but it would make submitting,
pulling, revewing, collaborating on, and merging patches much easier.

>> Also, in my vastly finite experience with github, I've had problems with the
>> fact that pull requests seem to be immutable: once a request has been
>> created, it doesn't seem to be easy to add more commits to it, or change the
>> commits. (This may just be my naïvety.)
>
> No, you can keep pushing to the branch you created the PR from, and
> new commits show up as they are made.  You can even rebase and force
> push, and the PR will get rebased too.  We do the first all the time,
> and the second also, though less frequently.

What happens to (inline) comments in this case?

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Jason Grout]

On 2/21/12 1:17 PM, Fernando Perez wrote:

Yes.  Typically one or more core committers participate in the
discussion, and it's easy to informally choose who does the final
merge.  But if you want to be more formal about it, there's an
assignee field and a project can choose to use it explicitly and
require that person to be the one who does the actual final merge.


Interesting.  Where is this assignee field?  Is it the assignee field in 
the Issues?  Does setting that require that the committer be the assignee?


Thanks,

Jason

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Fernando Perez]

On Tue, Feb 21, 2012 at 11:03 AM, Christopher Swenson
 wrote:
> My only possible issue with the github workflow: I'm not sure how it
> interacts with having multiple people who have control of the "master"
> (central) repo. When a pull request comes in, can anyone who has push access
> to the repo take control of that pull request?

Yes.  Typically one or more core committers participate in the
discussion, and it's easy to informally choose who does the final
merge.  But if you want to be more formal about it, there's an
assignee field and a project can choose to use it explicitly and
require that person to be the one who does the actual final merge.

> Also, in my vastly finite experience with github, I've had problems with the
> fact that pull requests seem to be immutable: once a request has been
> created, it doesn't seem to be easy to add more commits to it, or change the
> commits. (This may just be my naïvety.)

No, you can keep pushing to the branch you created the PR from, and
new commits show up as they are made.  You can even rebase and force
push, and the PR will get rebased too.  We do the first all the time,
and the second also, though less frequently.

Cheers,

f

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Jason Grout]

On 2/21/12 1:03 PM, Christopher Swenson wrote:

I agree with a lot of what was just said.

My only possible issue with the github workflow: I'm not sure how it
interacts with having multiple people who have control of the "master"
(central) repo. When a pull request comes in, can anyone who has push
access to the repo take control of that pull request?


Yes.  A pull request is just a remote branch.  Anyone with commit access 
to the repository can merge the remote branch and push to the github 
repository.





Also, in my vastly finite experience with github, I've had problems with
the fact that pull requests seem to be immutable: once a request has
been created, it doesn't seem to be easy to add more commits to it, or
change the commits. (This may just be my naïvety.)


Again, a pull request is just a remote branch.  If I have submitted a 
pull request, that just means that I've submitted a certain branch for 
merging.  If I push more commits to that branch, they automatically show 
up in the pull request.  In fact, I can rebase the branch and push -f 
the branch and the new commits will overwrite whatever was there.


One thing I like about github is that it is so close to the underlying 
git philosophy, so that once you understand git, it's easy to understand 
github.






But other than, I think github does have a great model. Is github on the
table for a future platform to move to?


Yes.  We've already moved the Sage notebook and the Sage Cell server to 
github.





I think gerrit is definitely a heavy-handed approach to reviews that
seems to work better with larger products (like Android), since you do
sort of have to adapt to its style of reviews.  And I don't know if it
is the right tool for Sage (not sure if anything is), but it is
certainly worth looking at.



Thanks again for your help with understanding gerrit better!

Jason


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Christopher Swenson]

I agree with a lot of what was just said.

My only possible issue with the github workflow: I'm not sure how it
interacts with having multiple people who have control of the "master"
(central) repo. When a pull request comes in, can anyone who has push
access to the repo take control of that pull request?

Also, in my vastly finite experience with github, I've had problems with
the fact that pull requests seem to be immutable: once a request has been
created, it doesn't seem to be easy to add more commits to it, or change
the commits. (This may just be my naïvety.)

But other than, I think github does have a great model. Is github on the
table for a future platform to move to?

I think gerrit is definitely a heavy-handed approach to reviews that seems
to work better with larger products (like Android), since you do sort of
have to adapt to its style of reviews.  And I don't know if it is the right
tool for Sage (not sure if anything is), but it is certainly worth looking
at.

--Christopher


On Tue, Feb 21, 2012 at 13:52, Fernando Perez  wrote:

> On Tue, Feb 21, 2012 at 7:38 AM, Jason Grout
>  wrote:
> > I'll have to think more about whether I agree with the "each commit
> should
> > stand on its own" philosophy mentioned below.  It certainly makes
> bisection
> > easier.  But sometimes huge patches make me think that each *branch*
> should
> > stand on its own, and be merged with no fast-forward. Then it's much
> easier
> > to tease apart logically separate, but interrelated, sets of changes.
>
> Many thanks for this super useful discussion!  From my own experience
> with github's branch-based review model, I lean strongly towards the
> view you summarize above.  I prefer to let authors make very liberal
> use of the commit abilities in git and review with the branch as the
> 'atomic unit' I worry about, giving only secondary consideration to
> individual commits.
>
> Obviously if the commit history is a complete mess we may require that
> it gets rebased and cleaned up, but in general we tend to be
> relatively lax with how the individual commits stack up, as long as
> the entire branch diff is sensible and easy to analyze on its own.
>
> From our own experience in ipython with github and how unbelievably
> fluid this has made the process both for new contributors and for
> reviewers, I think I really prefer this over the view that gerrit
> seems to propose.  But it's been very enlightening to read their
> rationale, and I certainly see it as a coherent perspective one can
> choose to adopt.
>
> Cheers,
>
> f
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Fernando Perez]

On Tue, Feb 21, 2012 at 7:38 AM, Jason Grout
 wrote:
> I'll have to think more about whether I agree with the "each commit should
> stand on its own" philosophy mentioned below.  It certainly makes bisection
> easier.  But sometimes huge patches make me think that each *branch* should
> stand on its own, and be merged with no fast-forward. Then it's much easier
> to tease apart logically separate, but interrelated, sets of changes.

Many thanks for this super useful discussion!  From my own experience
with github's branch-based review model, I lean strongly towards the
view you summarize above.  I prefer to let authors make very liberal
use of the commit abilities in git and review with the branch as the
'atomic unit' I worry about, giving only secondary consideration to
individual commits.

Obviously if the commit history is a complete mess we may require that
it gets rebased and cleaned up, but in general we tend to be
relatively lax with how the individual commits stack up, as long as
the entire branch diff is sensible and easy to analyze on its own.

>From our own experience in ipython with github and how unbelievably
fluid this has made the process both for new contributors and for
reviewers, I think I really prefer this over the view that gerrit
seems to propose.  But it's been very enlightening to read their
rationale, and I certainly see it as a coherent perspective one can
choose to adopt.

Cheers,

f

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sage-5.0.x and OS X 10.7 Lion

[Justin C. Walker]

On Feb 21, 2012, at 08:13 , R. Andrew Ohana wrote:

> On Tue, Feb 21, 2012 at 07:08, Dima Pasechnik  wrote:
>> In gmane.comp.mathematics.sage.devel, you wrote:
>>> On Mon, Feb 20, 2012 at 4:28 AM, Dima Pasechnik  wrote:
 Can we get Lion on bsd.math.washington.edu ?
>>> 
>>> I could, but then we will no longer have a 10.6 build/test machine, I
>>> think, and that would be bad.
>>> Also, I can't do this until next week, since I'm in San Diego right now.
>>> 
>> sure, I understand, but it seems that 10.7 is becoming a major hassle to
>> support, and so having a machine running it available would really be
>> great…

> FYI, sqrt5 has been down for awhile since it is extremely prone to
> kernel panics and I have yet to figure out the issue. My guess at this
> point in time is that these are due to it using the 32-bit kernel,
> which apple clearly isn't supporting any more -- the main requirement
> of 10.8 over 10.7 is support for the 64-bit kernel.

Is this true?  My 10.7 system has a 64-bit kernel, at least according to 'file':

$ file /mach_kernel 
/mach_kernel: Mach-O universal binary with 2 architectures
/mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
/mach_kernel (for architecture i386):   Mach-O executable i386

Justin

--
Justin C. Walker
Director
Institute for the Enhancement of the Director's Income
--
Fame is fleeting, but obscurity
   just drags on and on.  F&E



-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Jason Grout]

On 2/21/12 12:19 PM, Robert Bradshaw wrote:

Perhaps we could require that every state
of the main line be consistant, and if it's worthwhile to preserve
inconsistent history we merge it as a branch rather than rebasing.


That seems very reasonable to me.

Thanks,

Jason


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Robert Bradshaw]

On Tue, Feb 21, 2012 at 7:43 AM, Christopher Swenson
 wrote:
> Well, I believe that gerrit was designed with the Google philosophy in mind,
> so I would assume that this would mean that the software must run after each
> commit that is mailed out.  (This is sort of equivalent to the way patches
> work now, as they cannot be committed unless all tests pass.)
>
> There are some exceptions, naturally: when large, new sections of code are
> being developed, it is not unheard of to accept commits that don't actually
> work.

It gets a bit fuzzier when there are multiple authors on a single
feature, spread out through time. I think this is more common for a
project like Sage (lots of very-part-time contributors). It can also
be handy to spread out history into smaller or logical chunks (e.g.
big automatic renames/file moves, and then manual fixups, where the
former might not give a consistant state but is easy to review because
it's just the result of a sed script). I do, however, like the model
of iteratively working on a feature, including incorporating peer
feedback and fixes, adn then squashing the history down into a single
coherent commit at the end. Perhaps we could require that every state
of the main line be consistant, and if it's worthwhile to preserve
inconsistent history we merge it as a branch rather than rebasing.

- Robert

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: sage-5.0.x and OS X 10.7 Lion

[R. Andrew Ohana]

On Tue, Feb 21, 2012 at 07:08, Dima Pasechnik  wrote:
> In gmane.comp.mathematics.sage.devel, you wrote:
>> On Mon, Feb 20, 2012 at 4:28 AM, Dima Pasechnik  wrote:
>>> Can we get Lion on bsd.math.washington.edu ?
>>
>> I could, but then we will no longer have a 10.6 build/test machine, I
>> think, and that would be bad.
>> Also, I can't do this until next week, since I'm in San Diego right now.
>>
> sure, I understand, but it seems that 10.7 is becoming a major hassle to
> support, and so having a machine running it available would really be
> great...

I would rather not move bsd.math over to lion. We have a few machines
running lion currently and there is a tendency of crashing -- we don't
want that on bsd. I'm heading in later today to fix one of these
machines from such a crash, and when I do I'll be sure to make you an
account.

FYI, sqrt5 has been down for awhile since it is extremely prone to
kernel panics and I have yet to figure out the issue. My guess at this
point in time is that these are due to it using the 32-bit kernel,
which apple clearly isn't supporting any more -- the main requirement
of 10.8 over 10.7 is support for the 64-bit kernel. Unfortunately this
is a different requirement than simply having 64-bit hardware, since
apple has not and probably will not add 64-bit kernel support for many
of the early core 2 systems, which includes sqrt5's model.

>
> Dima
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



-- 
Andrew

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Jason Grout]

On 2/21/12 9:43 AM, Christopher Swenson wrote:

Well, I believe that gerrit was designed with the Google philosophy in
mind, so I would assume that this would mean that the software must run
after each commit that is mailed out.  (This is sort of equivalent to
the way patches work now, as they cannot be committed unless all tests
pass.)

There are some exceptions, naturally: when large, new sections of code
are being developed, it is not unheard of to accept commits that don't
actually work.



Thanks.  That sheds light on the subject.

Jason

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Christopher Swenson]

Well, I believe that gerrit was designed with the Google philosophy in
mind, so I would assume that this would mean that the software must run
after each commit that is mailed out.  (This is sort of equivalent to the
way patches work now, as they cannot be committed unless all tests pass.)

There are some exceptions, naturally: when large, new sections of code are
being developed, it is not unheard of to accept commits that don't actually
work.

--Christopher


On Tue, Feb 21, 2012 at 10:38, Jason Grout wrote:

> On 2/21/12 9:26 AM, Christopher Swenson wrote:
>
>> Jason,
>>
>> I forwarded this thread to Shawn Pearce, the primary author of gerrit,
>> and have included his response below.
>>
>
> Cool!  Thanks!
>
> I'll have to think more about whether I agree with the "each commit should
> stand on its own" philosophy mentioned below.  It certainly makes bisection
> easier.  But sometimes huge patches make me think that each *branch* should
> stand on its own, and be merged with no fast-forward. Then it's much easier
> to tease apart logically separate, but interrelated, sets of changes.
>  Maybe all that is going on here is miscommunication about what "stand on
> its own" means.  Does it mean that the software will run after each commit?
>  Or does it mean that each commit represents a single logical change,
> though it may temporarily put the software into an unreliable or
> error-ridden state?
>
>
> Jason
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@**
> googlegroups.com 
> For more options, visit this group at http://groups.google.com/**
> group/sage-devel 
> URL: http://www.sagemath.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: git and gerrit

[Jason Grout]

On 2/21/12 9:26 AM, Christopher Swenson wrote:

Jason,

I forwarded this thread to Shawn Pearce, the primary author of gerrit,
and have included his response below.


Cool!  Thanks!

I'll have to think more about whether I agree with the "each commit 
should stand on its own" philosophy mentioned below.  It certainly makes 
bisection easier.  But sometimes huge patches make me think that each 
*branch* should stand on its own, and be merged with no fast-forward. 
Then it's much easier to tease apart logically separate, but 
interrelated, sets of changes.  Maybe all that is going on here is 
miscommunication about what "stand on its own" means.  Does it mean that 
the software will run after each commit?  Or does it mean that each 
commit represents a single logical change, though it may temporarily put 
the software into an unreliable or error-ridden state?


Jason


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: git and gerrit

[Christopher Swenson]

Jason,

I forwarded this thread to Shawn Pearce, the primary author of gerrit, and
have included his response below.

--Christopher

-- Forwarded message --
From: Shawn Pearce 
Date: Tue, Feb 21, 2012 at 15:16
Subject: Re: [sage-devel] Re: git and gerrit
To: Christopher Swenson 
Cc: Christopher Swenson 


Inline below, feel free to forward this.

> -- Forwarded message --
> From: Jason Grout 
> Date: Thu, Feb 16, 2012 at 09:19
> Subject: [sage-devel] Re: git and gerrit
> To: sage-devel@googlegroups.com
>
>
> However, if I have a "topic" I'd like to commit, and all the commits
really
> should be reviewed as a package together, or if I'm collaborating with
> others on a branch, then it is incredibly convenient to look at patchsets
at
> a topic-branch level (ala github) rather than the individual commit level,
> like gerrit seems to be insisting.

Currently the topic branch author can include a topic name when
pushing their changes to Gerrit, e.g. "git push review
work:refs/for/master/my-topic" will upload the changes for the master
branch, with the topic label of my-topic. Reviews can click on the
"my-topic" label, or use a search query like "status:open
topic:my-topic" to find open changes with this label and review them.

Kitware has been working on topic branch support, where a topic branch
is a more fundamental concept in Gerrit that can be reviewed and
submitted as a unit. Unfortunately this work is still in progress and
has not made it to a release version yet.

>  It seems that the only way to get a
> topic-level view of things in gerrit is to insist that you squash all the
> commits into one commit, which is usually bad, in my opinion.

If the commits are going to be preserved in history, they should be
reviewed individually to ensure each commit is consistent on its own.
If it isn't, it shouldn't be in the history, and should therefore be
squashed together with something else, or removed altogether.
Reviewing the topic branch as a diff of its tip commit against the
common ancestor doesn't really provide a way to review each commit. So
it hasn't really been supported by Gerrit.

If you really need the overall diff in order to get a sense of what
the change is, you can fetch the tip commit from Gerrit and then run
`git diff` on your workstation to glance over the entire diff. Yes you
lose the ability to comment on individual chunks of code. But we (the
Gerrit community) stand behind the notion that if a commit is
worthwhile to keep forever as part of the project history, then it is
worthwhile to review on its own, and it must stand on its own to
justify being included in the project. Thus, this topic branch overall
diff isn't as useful as it sounds.

> It is nice that gerrit preserves the history of each individual commit
that
> is reviewed.  Can this history be pushed or mirrored somewhere else (e.g.,
> can I clone the gerrit repository and get these fake ref/for/master
> branches?)

Yes. Each change is given its own refs/changes/... branch name in the
Gerrit repository. These can be mirrored elsewhere using stock Git
tools, or the replication feature that is built into Gerrit. Users can
see what branch name was assigned by looking at a patch set on the
change page in the web UI. For each patch set Gerrit generates a
number of Git commands that can be used to fetch the change using this
unique branch name, and then perform common actions against it (e.g.
checkout, pull, cherry-pick, diff).

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: sage-5.0.x and OS X 10.7 Lion

[Dima Pasechnik]

In gmane.comp.mathematics.sage.devel, you wrote:
> On Mon, Feb 20, 2012 at 4:28 AM, Dima Pasechnik  wrote:
>> Can we get Lion on bsd.math.washington.edu ?
>
> I could, but then we will no longer have a 10.6 build/test machine, I
> think, and that would be bad.
> Also, I can't do this until next week, since I'm in San Diego right now.
>
sure, I understand, but it seems that 10.7 is becoming a major hassle to
support, and so having a machine running it available would really be
great...

Dima

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: log messages

[Keshav Kini]

Robert Bradshaw  writes:

> On Mon, Feb 20, 2012 at 8:21 PM, Keshav Kini  wrote:
>> The following would occur when you did `sage -b`:
>>
>> 1. sage-.ebuild would be copied out of the Sage library tree,
>>   specifically out of the tree of the revision at the head of the
>>   trac-12345 branch of the Sage library repository
>> 2. This sage-.ebuild would be placed in the portage tree (not under
>>   version control, but just dumped there), in say
>>   lmonade/dist/portage/sci-mathematics/sage/
>> 3. `emerge =sage-` would be called, thus explicitly building
>>   sage-.ebuild
>> 4. Since sage-.ebuild came from the revision at trac-12345, the
>>   dependencies listed therein would include the correct versions of
>>   packages required for that trac ticket; the authors of the trac
>>   ticket, at the same time as committing the changed sage-.ebuild
>>   into the Sage library, would have also committed updated ebuilds for
>>   the new packages required, into the package repository. Or those
>>   updated ebuilds would already have been committed there earlier. Thus
>>   they would now be pulled in by the building of sage-.ebuild.
>>
>> This seems to be pretty much what you want, right? The only catch I see
>> is that possibly there might be delays in getting the new ebuilds into
>> the package repository, whereas publishing your topic branch of the Sage
>> library is instant. But since it's supposed to be a rolling release
>> repo (unlike the Sage library repo), hopefully this won't be so bad.
>> And if the ticket author is really impatient, he can publish his own
>> branch of the package repo too, for you to pull from before running
>> `sage -b`.
>
> This is exactly the issue. Currently, a ticket is not merged until it
> has been reviewed. Otherwise the options are to (1) give everyone who
> wants to contribute commit rights to the package repository, pushing
> *before* any review or (2) wait for manual intervention by someone
> with permissions to push to the package repository, again before a
> review or (3) publish your own branch, separate from your library
> changes, with instructions to pull from that or (4) post a patch file,
> like we do now. Completely independent from the packaging/building
> issues, throwing a second repository into the mix significantly
> complicates things.

Yeah, this is not a great situation. If I had to choose among the four
options you enumerated, I would choose (2). If I'm not mistaken we
already have "maintainers" of SPKGs, so it would be comparable to that,
but I agree that it would be better if you didn't have to go through a
maintainer in order to add a patch to a package, or even generally if
you didn't have to publish your experimental new patch setup to the
public repository which everyone is pulling from, even if it were a
patch setup that nobody would ever actually use, thanks to strict
version dependencies. And that last requirement moves us towards picking
(3), which is an awkward situation. You're right, this is starting to
sound too complicated again. Hmm... I will have to think about this some
more.

> (On another note, I would like the Sage library repo to be a rolling
> release as well, at least as an option. Named releases are important
> as well.)

Sure, that shouldn't present any difficulties with Prefix as far as I
can see, as long as we keep a public repository, which is something that
we are very far from doing right now, what with Jeroen destroying all
development releases after they become outdated, and all, but is
something that should definitely happen once we switch to git,
thankfully.

>>> Upgrading to the latest alpha
>>> (or even more find-grained versions) would be "git pull" which is
>>> something that's also really lacking in our current workflow. All of
>>> this requires a repository.
>>
>> One could upgrade to the latest alpha by just pulling with the above
>> setup, too. The point is that the package repository would contain all
>> past and future versions and patch versions of packages, within reason
>> (maybe we would delete extremely old versions). So even if you had an
>> old version of Sage, the newest versions of other packages would already
>> have their ebuilds in your package repository, even if you hadn't been
>> able to install them due to your old version of Sage requiring older
>> versions of the packages. Once you pulled the alpha into your Sage
>> library, sage-.ebuild would now let you install the new package
>> versions. And if you checked out your old version of Sage again, those
>> packages would be downgraded again the next time you did `sage -b`.
>
> Yes, this would work, provided the two repositories are manually kept
> in sync (or, specifically, the package repository is at least as fresh
> as the library repository). There is the significant advantage that
> things won't silently break if they're not in sync, and it's nicer in
> the case of alphas than pre-reviewed tickets, but it's still