Re: [sage-devel] Re: sage fails to build on (fresh install of) debian linux 8.4 (64 bit)...

[Dima Pasechnik]

probably Jmol problem is Java-related, i.e. it perhaps needs a different 
version of Java, or at least some working Java version.


On Sunday, May 29, 2016 at 6:17:46 AM UTC+1, Eric Larson wrote:
>
> Hi all,
>
> Yes, sage mostly works --- except I cannot create a 3D graphics object:
>
> sage: point3d((0, 0, 0))
> /home/eric/sage-src/local/lib/python2.7/site-packages/sage/repl/rich_output/display_manager.py:590:
>  
> RichReprWarning: Exception in _rich_repr_ while displaying object: Jmol 
> failed to create file 
> '/home/eric/.sage/temp/serre/4032/dir_Kn6nvZ/preview.png', see 
> '/home/eric/.sage/temp/serre/4032/tmp_UBdIvW.txt' for details
>   RichReprWarning,
> Graphics3d Object
> sage:
>
> The file /home/eric/.sage/temp/serre/4032/tmp_UBdIvW.txt disappears after 
> exiting sage; but while sage is still running, I can view it, and it 
> contains the following text:
>
> Error: Unable to access jarfile 
> /home/eric/sage-src/local/share/jmol/JmolData.jar
>
> The directory /home/eric/sage-src/local/share/jmol/ does not exist:
>
> eric@serre:~$ cd /home/eric/sage-src/local/share/jmol/
> bash: cd: /home/eric/sage-src/local/share/jmol/: No such file or directory
> eric@serre:~$ cd /home/eric/sage-src/local/share/
> eric@serre:~/sage-src/local/share$ ls
> aclocal dociml  lrcalc   maxima  singular
> cliquer gc info man  paritabset
> conway_polynomials  gcc-4.9.3  jupyter  mathjax  sageterminfo
> eric@serre:~/sage-src/local/share$ 
>
> Best,
> -Eric
>
> On Saturday, May 28, 2016 at 8:04:37 PM UTC-4, vdelecroix wrote:
>>
>> The error occurred during the documentation build. You should be able to 
>> start Sage without any problem. 
>>
>> If it works, try to create some 3d plots and see them (via jmol). 
>>
>> On 28/05/16 17:35, Eric Larson wrote: 
>> > ...But I can attach a google drive link to the file: 
>> > ​ 
>> >   install.log 
>> > <
>> https://drive.google.com/file/d/0BzxearNxPfAuTGZ3YVFvS0dHN1U/view?usp=drive_web>
>>  
>>
>> > ​ 
>> > 
>> > On Sat, May 28, 2016 at 6:29 PM, Eric Larson  
>> wrote: 
>> > 
>> >> Hi Dima, 
>> >> 
>> >> Hm... I think most of the issue was that my fresh install of debian 8 
>> was 
>> >> from the initial release CD, which included a buggy compiler? Because 
>> when 
>> >> I ran system updates, I noticed that one of the things updated was 
>> gcc, and 
>> >> figured I should try recompilation. This time I get a *different* 
>> error 
>> >> --- sage itself builds fine, and appears to run fine, unlike last 
>> time, but 
>> >> it was unable to build the documentation: 
>> >> 
>> >> [plot3d   ] RuntimeError: Jmol failed to create file 
>> >> '/home/eric/.sage/temp/serre/31647/dir_gUwtRI/preview.png', see 
>> >> '/home/eric/.sage/temp/serre/31647/tmp_xSBzt6.txt' for details 
>> >> Error building the documentation. 
>> >> Traceback (most recent call last): 
>> >>File "/home/eric/sage-src/local/lib/python/runpy.py", line 162, in 
>> >> _run_module_as_main 
>> >>  "__main__", fname, loader, pkg_name) 
>> >>File "/home/eric/sage-src/local/lib/python/runpy.py", line 72, in 
>> >> _run_code 
>> >>  exec code in run_globals 
>> >>File 
>> >> 
>> "/home/eric/sage-src/local/lib/python2.7/site-packages/sage_setup/docbuild/__main__.py",
>>  
>>
>> >> line 2, in  
>> >>  main() 
>> >>File 
>> >> 
>> "/home/eric/sage-src/local/lib/python2.7/site-packages/sage_setup/docbuild/__init__.py",
>>  
>>
>> >> line 1629, in main 
>> >>  builder() 
>> >>File 
>> >> 
>> "/home/eric/sage-src/local/lib/python2.7/site-packages/sage_setup/docbuild/__init__.py",
>>  
>>
>> >> line 284, in _wrapper 
>> >>  getattr(get_builder(document), 'inventory')(*args, **kwds) 
>> >>File 
>> >> 
>> "/home/eric/sage-src/local/lib/python2.7/site-packages/sage_setup/docbuild/__init__.py",
>>  
>>
>> >> line 495, in _wrapper 
>> >>  x.get(9) 
>> >>File 
>> "/home/eric/sage-src/local/lib/python/multiprocessing/pool.py", 
>> >> line 567, in get 
>> >>  raise self._value 
>> >> OSError: [plot3d   ] 
>> >> 
>> /home/eric/sage-src/local/lib/python2.7/site-packages/sage/plot/plot3d/platonic.py:docstring
>>  
>>
>> >> of sage.plot.plot3d.platonic:10: WARNING: Exception occurred in 
>> plotting 
>> >> platonic-1 
>> >> 
>> >> Makefile:1003: recipe for target 'doc-html' failed 
>> >> make[2]: *** [doc-html] Error 1 
>> >> make[2]: Leaving directory '/home/eric/sage-src/build/make' 
>> >> Makefile:826: recipe for target 'all' failed 
>> >> make[1]: *** [all] Error 2 
>> >> make[1]: Leaving directory '/home/eric/sage-src/build/make' 
>> >> 
>> >> real  314m1.704s 
>> >> user  286m3.212s 
>> >> sys   12m12.704s 
>> >> *** 
>> >> Error building Sage. 
>> >> 
>> >> The following package(s) may have failed to build (not necessarily 
>> >> during this run of 'make all'): 
>> >> 
>> >> * documentation: dochtml 
>> >>log file: /home/eric/sage-src/logs/pkgs/../dochtml

Re: [sage-devel] Re: Copyrights

[rjf]

On Friday, May 27, 2016 at 10:34:38 AM UTC-7, William wrote:
>
> On Fri, May 27, 2016 at 10:30 AM, rjf > 
> wrote: 
> > So you should claim authorship and copyright, and then declare that 
> others 
> > may 
> > use it under whatever restrictions you determine.  Personally, I find 
> the 
> > MIT or 
> > Berkeley licenses much better than GPL, since they let anyone use the 
> code 
> > for any purpose and don't insist on other conditions. 
>
> Curious: I always imagined that you were the main force behind the 
> open sourcing of Maxima.  Why is the Maxima license GPL instead of MIT 
> or Berkeley? 
>

I was the main force in making the Macsyma code available via the Dept. of 
Energy
(a principal, but not sole, sponsor of the Macsyma project at MIT.)  The 
powers
at MIT, including my de facto advisor, Joel Moses, wished to take advantage 
of a
gov't rule that gave the academic institution ownership rights to software 
developed
under gov't sponsorship.  Through a somewhat convoluted process this 
resulted
in the sale of exclusive commercial rights to Macsyma to Symbolics Inc.  
In retrospect I think everyone would concede this was a bad idea.  I forced 
MIT to
put a copy officially in the Dept of Energy software library; they put a 
broken copy
there.  I fixed it up to run "out of the box" on DEC VAX computers running 
Berkeley UNIX  (or, with some help, VAX/VMS).  It was not yet free because 
DOE
charged a few hundred dollars, and as a concession to MIT did not allow 
redistribution.
This version used Franz Lisp which we wrote at Berkeley. Franz Lisp was 
free/open
part of Berkeley UNIX.
Bill Schelter modified the Macsyma code and added extra pieces and got it 
running
under Kyoto Common Lisp (which he changed and named Austin-Kyoto Common 
Lisp)
and then became GCL.

Bill also conferred with DOE and asked for permission to release 
DOE-Macsyma under
GPL.  At that time DOE was, I think, giving up on their library business, 
and so agreed.

I think they would have equally well released it under BSD or MIT open 
source license
if Bill had asked for that. I read the permission letter as a "whatever" 
 permission.

I had some discussion about the appropriateness of GPL, but Bill's untimely 
death cut
that off.  

My view then, was  that a company with some expertise and resources could
have taken the DOE Macsyma code and possibly acquired the commercial 
Symbolics
Macsyma code (by this time the company was defunct), and improved/ 
supported/ the code.
Putting it under GPL was more-or-less poison to such enterprises, RedHat 
etc to the
contrary.  The market for Macsyma would be much smaller than Unix.  

Why did Symbolics, and then later Macsyma Inc, a spin off, fail?  1. They 
wanted to sell
hardware (Lisp Machines) even though the real winner for the software was 
VAX and
Sun hardware [the enemy of Lisp machines]. 2. (I suspect) A collection of 
incorrect
decisions at the marketing and management level.

Has GPL achieved its goal with respect to Macsyma / Maxima?
Yes, there is no  secret version for sale.

Side effect: There is no commercial support for it; 
at least to my knowledge, not a single person has
earned a single penny "selling" Macsyma or services, or add-ons.
Side effect: The possibility of research funding from a commercial
enterprise is essentially zero.  (huh, you say?)   Historically, the
Maple company sponsored research at Univ. Waterloo, in the area
of computer algebra.  

Given the paucity of NSF or other gov't funding for academic research,
some schools have found substantial support from private companies.
I think Sage has received small grants from Microsoft.  
My institution / department has received massive amounts of funding
from companies like Microsoft, Apple, Google, etc.   I don't know if
these donors would have been turned off by GPL.

http://ipira.berkeley.edu/about-us  is the web page for Berkeley 
intellectual
property management;  they used to be grossly incompetent regarding
software, but I don't know about this now. 

Given the possible continuing govt funding drought for Sage, it would
be ironic if the founding principle for Sage --of GPL for everything --
turns out to be a factor in its financial difficulties.On the other 
hand,
I am not claiming that a commercial enterprise "doing Sage" would
be so successful that it would spread money far and wide to researchers.
I would not expect investors to find grounds to support Sage Inc.
It seems to me to be a very small market to try to sell software to
mathematics professionals. (cf. Magma).
I have advised students to seek other software project areas if their
primary goal is to make big money from some startup.

Anyway,  the simple answer to the original question is -- I wanted a more
open license for DoE Macsyma, but  GPL was Bill Schelter's choice, and
people seemed to like it that way.  

>
>
RJF

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from thi

Re: [sage-devel] Re: Copyrights

[William Stein]

On Sun, May 29, 2016 at 12:22 AM, rjf  wrote:
>
>
> On Friday, May 27, 2016 at 10:34:38 AM UTC-7, William wrote:
>>
>> On Fri, May 27, 2016 at 10:30 AM, rjf  wrote:
>> > So you should claim authorship and copyright, and then declare that
>> > others
>> > may
>> > use it under whatever restrictions you determine.  Personally, I find
>> > the
>> > MIT or
>> > Berkeley licenses much better than GPL, since they let anyone use the
>> > code
>> > for any purpose and don't insist on other conditions.
>>
>> Curious: I always imagined that you were the main force behind the
>> open sourcing of Maxima.  Why is the Maxima license GPL instead of MIT
>> or Berkeley?
>
>
> I was the main force in making the Macsyma code available via the Dept. of
> Energy
> (a principal, but not sole, sponsor of the Macsyma project at MIT.)  The
> powers
> at MIT, including my de facto advisor, Joel Moses, wished to take advantage
> of a
> gov't rule that gave the academic institution ownership rights to software
> developed
> under gov't sponsorship.  Through a somewhat convoluted process this
> resulted
> in the sale of exclusive commercial rights to Macsyma to Symbolics Inc.
> In retrospect I think everyone would concede this was a bad idea.  I forced
> MIT to
> put a copy officially in the Dept of Energy software library; they put a
> broken copy
> there.  I fixed it up to run "out of the box" on DEC VAX computers running
> Berkeley UNIX  (or, with some help, VAX/VMS).  It was not yet free because
> DOE
> charged a few hundred dollars, and as a concession to MIT did not allow
> redistribution.
> This version used Franz Lisp which we wrote at Berkeley. Franz Lisp was
> free/open
> part of Berkeley UNIX.
> Bill Schelter modified the Macsyma code and added extra pieces and got it
> running
> under Kyoto Common Lisp (which he changed and named Austin-Kyoto Common
> Lisp)
> and then became GCL.
>
> Bill also conferred with DOE and asked for permission to release DOE-Macsyma
> under
> GPL.  At that time DOE was, I think, giving up on their library business,
> and so agreed.
>
> I think they would have equally well released it under BSD or MIT open
> source license
> if Bill had asked for that. I read the permission letter as a "whatever"
> permission.
>
> I had some discussion about the appropriateness of GPL, but Bill's untimely
> death cut
> that off.

Thanks for sharing the above/below history!

> Side effect: There is no commercial support for it;
> at least to my knowledge, not a single person has
> earned a single penny "selling" Macsyma or services, or add-ons.

SageMath, Inc., sells use of Sage (via https://cloud.sagemath.com),
and Sage significantly uses Maxima.  SageMathCloud also has a notebook
that can be used in Maxima mode.   Also, SageMath, Inc. provides
commercial support to users.  SageMath, Inc. has earned at least a
single penny in revenue.


-- 
William (http://wstein.org)

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] trac's automerging error

[jhonrubia6]

I noticed some typos on #10180 so I prepared a patch and committed, but now 
I see the branch in red in trac ticketing system and an error "trac's auto 
merging failed"
maybe the ticket was already closed  even if the status was needs_review , 
I do not understand this error, nor how to solve it. 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: trac's automerging error

[Volker Braun]

It means that our trac plugin had problems mergin in the lastest beta. You 
should try to merge yourself, and see if there are any conflicts. If there 
are conflicts: resolve and push. Its possible that manual merge succeeds 
because the git commandline client is better at merging, in that case you 
can ignore the error (though you might want to push the merge, too, to 
enable the online diff viewer)

On Sunday, May 29, 2016 at 2:47:35 PM UTC+2, jhonrubia6 wrote:
>
> I noticed some typos on #10180 so I prepared a patch and committed, but 
> now I see the branch in red in trac ticketing system and an error "trac's 
> auto merging failed"
> maybe the ticket was already closed  even if the status was needs_review , 
> I do not understand this error, nor how to solve it. 
>

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: [sage-notebook] Coming SageMathCell upgrade - please test!

[Andrey Novoseltsev]

On Thursday, 26 May 2016 10:34:10 UTC-6, kcrisman wrote:
>
>
> Please report any new (or old) errors that you notice - I will try to 
>> fix them tomorrow (Saturday) afternoon (MST) and on Sunday/Monday. If 
>> something is horribly wrong and I can't resolve it by Monday evening, 
>> I'll pull back to the old version. 
>>
>>
>
> http://ask.sagemath.org/question/33555/problem-with-encoding-german-characters/
>  
> could be related, or so the poster seems to imply - though probably not bad 
> enough to go back before 7.2. 
>

This should be fixed now - I had to encode user code when writing to a file 
for correct warning messages.

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Renaming generic curve classes

[Grayson Jorgenson]

Hi all,

I am working on revising the class structure for generic curves to make it 
easier to implement functionality for the GSoC 2016 project on algebraic 
curves. The main curve classes right now are ProjectiveSpaceCurve_generic, 
ProjectiveCurve_generic, AffineSpaceCurve_generic, and AffineCurve_generic, 
with ProjectiveCurve_generic and AffineCurve_generic representing plane 
curves. The implementations of these classes reside in 
/schemes/plane_curves.

Currently, the plane curve classes do not inherit from the space curve 
classes and there isn't any functionality specific to the space curve 
classes. The goal of ticket #20697  is 
to make the plane curve classes inherit the space curve classes so that the 
space curve classes act as the generic classes for projective/affine 
curves. However, doing this makes the class names a bit inaccurate, since 
for example the ProjectiveCurve_generic class really represents plane 
curves and ProjectiveSpaceCurve_generic is the more general class. It seems 
that it would be a lot clearer to have a different naming scheme, such as 
having ProjectiveCurve_generic be called ProjectiveCurve_plane, and having 
ProjectiveSpaceCurve_generic be called ProjectiveCurve_generic (similarly 
for the affine curve classes).

Is there a policy for changing class names in Sage? Also, since there 
eventually will be more functionality implemented for generic curves and 
not just plane curves, would it be possible to rename the plane_curves 
folder to something more general such as "curves" or "curves_generic"?

Thank you,
Grayson

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Renaming generic curve classes

[Johan S . R . Nielsen]

Hi Grayson,

I'm really looking forward to your GSoC on curves!

> Currently, the plane curve classes do not inherit from the space curve 
> ...
> It seems that it would be a lot clearer to have a different naming
> scheme, such as having ProjectiveCurve_generic be called
> ProjectiveCurve_plane, and having ProjectiveSpaceCurve_generic be
> called ProjectiveCurve_generic (similarly for the affine curve
> classes).

I think that makes sense: if you restructure the class hierarchy to
modernise and accommodate more powerful code sharing, it makes sense to
rename. I would say that you shouldn't feel too many constraints wrt.
restructuring/renaming these specific structures if it makes sense in
the long run. I haven't been involved in sage.schemes, however, so
someone more invested in that folder might disagree. I believe that the
curves structure hasn't been refactored much from the very first years
of Sage.

I'm a bit surprised at the naming scheme "_generic", etc. in the first
place. We don't use that very often, and it's not very Pythonic. Would a
completely different and simpler naming scheme be appropriate? E.g.:

ProjectiveCurve  - the generic class
ProjectivePlaneCurve - the plane curves

as well as AffineCurve, AffinePlaneCurve (or simply Curve and
PlaneCurve? I.e. you get affine if you don't ask for projective?).

Are you envisioning other specialisations than plane?

Also, you should think about which constructors you want to import in the
top-level, and which constructors should be accessible from a catalogue,
e.g. curves..

Technically, the renaming can get a bit tricky with deprecation
warnings, especially if you're reusing a name for another thing.

> Also, since there eventually will be more functionality implemented
> for generic curves and not just plane curves, would it be possible to
> rename the plane_curves folder to something more general such as
> "curves" or "curves_generic"?

I vote for "curves". Everything without a specialising denotation is
generic by default ;-)

I don't know how this works wrt. deprecation. If you rename a folder
which contains functions that were meant to be "top-level importable",
you need to still make that module name available with a deprecation
warning. That might require dynamically injecting a module into the
sage.schemes?


Best,
Johan


Grayson Jorgenson writes:

> Hi all,
>
> I am working on revising the class structure for generic curves to make it 
> easier to implement functionality for the GSoC 2016 project on algebraic 
> curves. The main curve classes right now are ProjectiveSpaceCurve_generic, 
> ProjectiveCurve_generic, AffineSpaceCurve_generic, and AffineCurve_generic, 
> with ProjectiveCurve_generic and AffineCurve_generic representing plane 
> curves. The implementations of these classes reside in 
> /schemes/plane_curves.
>
> Currently, the plane curve classes do not inherit from the space curve 
> classes and there isn't any functionality specific to the space curve 
> classes. The goal of ticket #20697  is 
> to make the plane curve classes inherit the space curve classes so that the 
> space curve classes act as the generic classes for projective/affine 
> curves. However, doing this makes the class names a bit inaccurate, since 
> for example the ProjectiveCurve_generic class really represents plane 
> curves and ProjectiveSpaceCurve_generic is the more general class. It seems 
> that it would be a lot clearer to have a different naming scheme, such as 
> having ProjectiveCurve_generic be called ProjectiveCurve_plane, and having 
> ProjectiveSpaceCurve_generic be called ProjectiveCurve_generic (similarly 
> for the affine curve classes).
>
> Is there a policy for changing class names in Sage? Also, since there 
> eventually will be more functionality implemented for generic curves and 
> not just plane curves, would it be possible to rename the plane_curves 
> folder to something more general such as "curves" or "curves_generic"?
>
> Thank you,
> Grayson


-- 

-- 
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.