Re: [sage-devel] Build error in Sage-6.2: pynac-0.3.2

[Vincent Delecroix]

>From your logs it seems to be a permission problem. What user own
/opt/sage-6.2 ? and what are the permissions ?

2014-06-07 3:15 UTC+02:00, Alasdair :
> Here's the error as reported during the compilation process:
>
> checking for python... /opt/sage-6.2/local/bin/python
>> checking for a version of Python >= '2.1.0'... sys:1: RuntimeWarning: not
>>
>> adding directory '' to sys.path since it's writable by an untrusted
>> group.
>> Untrusted users could put files in this directory which might then be
>> imported by your Python code. As a general precaution from similar
>> exploits, you should not execute Python code from this directory
>> yes
>> checking for the distutils Python package... no
>> configure: error: cannot import Python module "distutils".
>> Please check your Python installation. The error was:
>> sys:1: RuntimeWarning: not adding directory '' to sys.path since it's
>> writable by an untrusted group.
>> Untrusted users could put files in this directory which might then be
>> imported by your Python code. As a general precaution from similar
>> exploits, you should not execute Python code from this directory
>> make[3]: Entering directory
>> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
>> make[3]: *** No targets specified and no makefile found.  Stop.
>> make[3]: Leaving directory
>> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
>> Error building pynac.
>>
>> real0m0.869s
>> user0m0.528s
>> sys 0m0.384s
>> 
>> Error installing package pynac-0.3.2
>> 
>> Please email sage-devel (http://groups.google.com/group/sage-devel)
>> explaining the problem and including the relevant part of the log file
>>   /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
>> Describe your computer, operating system, etc.
>> If you want to try to fix the problem yourself, *don't* just cd to
>> /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2 and type 'make' or
>> whatever is appropriate.
>> Instead, the following commands setup all environment variables
>> correctly and load a subshell for you to debug the error:
>>   (cd '/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2' &&
>> '/opt/sage-6.2/sage' --sh)
>> When you are done debugging, you can type "exit" to leave the subshell.
>> 
>> make[2]: *** [/opt/sage-6.2/local/var/lib/sage/installed/pynac-0.3.2]
>> Error 1
>> make[2]: Leaving directory `/opt/sage-6.2/build'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/opt/sage-6.2/build'
>>
>> real150m50.768s
>> user131m18.168s
>> sys 17m8.948s
>> ***
>> Error building Sage.
>>
>> The following package(s) may have failed to build:
>>
>> package: pynac-0.3.2
>> log file: /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
>> build directory: /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2
>>
>> The build directory may contain configuration files and other potentially
>> helpful information. WARNING: if you now run 'make' again, the build
>> directory will, by default, be deleted. Set the environment variable
>> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>>
>> make: *** [build] Error 1
>>
>
> I'm attempting this on a new installation of kubuntu 14.04 64-bit.  This is
>
> the first time, in maybe 20 Sage compilations over the years, that I've
> encountered an error.  I've aso checked that I do have distutils, it was
> installed when I installed Python initially (version 2.7); there is also
> distutils for Python 3.4; I imagine loaded as part of the Sage compile
> process.
>
> Any advice?
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Logs for aleph.sagemath.org

[Ivan Andrus]

On Jun 6, 2014, at 7:11 AM, Jason Grout  wrote:

> On 6/5/14, 2:33, Ivan Andrus wrote:
>> Are there logs (and if so where are they?) for aleph.sagemath.org?  I'm 
>> trying to figure out what sorts of things the iOS app is used for.
> 
> Yes, there are logs.   Right now, we log remote ip, referer, execution type, 
> kernel id, and the code text: 
> https://github.com/sagemath/sagecell/blob/master/log.py
> 
> That's a good idea to log the user agent too, but we don't have historical 
> data on that (at least from the ios app)

I looked on boxen but can't find the log files (maybe I need access to 
/home/sagenb?).  Then (I thought) I remembered it was moved off of boxen, but I 
couldn't find where to in the archives.

Anyway, it would still be interesting to know what people are doing in general, 
but if I can't separate out the app, it's less useful I suppose.

Thanks,
Ivan

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Build error in Sage-6.2: pynac-0.3.2

[Alasdair]

Here's the error as reported during the compilation process:

checking for python... /opt/sage-6.2/local/bin/python
> checking for a version of Python >= '2.1.0'... sys:1: RuntimeWarning: not 
> adding directory '' to sys.path since it's writable by an untrusted group.
> Untrusted users could put files in this directory which might then be 
> imported by your Python code. As a general precaution from similar 
> exploits, you should not execute Python code from this directory
> yes
> checking for the distutils Python package... no
> configure: error: cannot import Python module "distutils".
> Please check your Python installation. The error was:
> sys:1: RuntimeWarning: not adding directory '' to sys.path since it's 
> writable by an untrusted group.
> Untrusted users could put files in this directory which might then be 
> imported by your Python code. As a general precaution from similar 
> exploits, you should not execute Python code from this directory
> make[3]: Entering directory 
> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
> make[3]: *** No targets specified and no makefile found.  Stop.
> make[3]: Leaving directory 
> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src'
> Error building pynac.
>
> real0m0.869s
> user0m0.528s
> sys 0m0.384s
> 
> Error installing package pynac-0.3.2
> 
> Please email sage-devel (http://groups.google.com/group/sage-devel)
> explaining the problem and including the relevant part of the log file
>   /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
> Describe your computer, operating system, etc.
> If you want to try to fix the problem yourself, *don't* just cd to
> /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2 and type 'make' or 
> whatever is appropriate.
> Instead, the following commands setup all environment variables
> correctly and load a subshell for you to debug the error:
>   (cd '/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2' && 
> '/opt/sage-6.2/sage' --sh)
> When you are done debugging, you can type "exit" to leave the subshell.
> 
> make[2]: *** [/opt/sage-6.2/local/var/lib/sage/installed/pynac-0.3.2] 
> Error 1
> make[2]: Leaving directory `/opt/sage-6.2/build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/opt/sage-6.2/build'
>
> real150m50.768s
> user131m18.168s
> sys 17m8.948s
> ***
> Error building Sage.
>
> The following package(s) may have failed to build:
>
> package: pynac-0.3.2
> log file: /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log
> build directory: /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2
>
> The build directory may contain configuration files and other potentially
> helpful information. WARNING: if you now run 'make' again, the build
> directory will, by default, be deleted. Set the environment variable
> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>
> make: *** [build] Error 1
>

I'm attempting this on a new installation of kubuntu 14.04 64-bit.  This is 
the first time, in maybe 20 Sage compilations over the years, that I've 
encountered an error.  I've aso checked that I do have distutils, it was 
installed when I installed Python initially (version 2.7); there is also 
distutils for Python 3.4; I imagine loaded as part of the Sage compile 
process.

Any advice?

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[kcrisman]

>
> Note that I would also need to triple MANY functions in the graph code, 
> for the very reason that you insist on writing Python code as if it were C 
> code.
>
>
Interesting, there are things like that in the optimization-based graph 
code too?
 

> I have been doing this in the Graph code for years. And I think that I 
> remember how it began :
>
> It was the early days of Linear Programming. I was writing functions to 
> solve NP hard stuff, returning partitions of vertices or list of vertices, 
> and though that perhaps I could save this with a "value_only" flag. When a 
> graph function has such a flag, it means that it will not return the actual 
> list of vertices, but its size instead.
>
> This, because in the optimization world, we deal with existence problems. 
> And existence problems have what is called a "certificate", ie "some 
> information which can be used to check, in polynomial time, that the answer 
> given to the decision problem is right".
>
> Thus in the graph code you will have functions with a "certificate" flag, 
> others with a "value_only" flag. And their output changes according to that.
>
> Python is *NOT* typed. Accept it.
>
>
I am very glad Python is dynamically typed!  For me, it has nothing to do 
with type, and everything to do with not confusing end users.  Especially 
because it seems (but I may have misunderstood some comments in the vast 
trove of emails and tickets) that one could get different output types 
without the use of special 'certificate' keywords.

I don't want to have to create objects that will be only used to access 
> methods.
> If I create those objects, I will need to write a OrthogonalArray class, a 
> TransversalDesign class, and these objects (which, currently, are lists of 
> lists) will HAVE to be immutable.
>

Actually, I was kind of surprised that they were just lists of lists when I 
was looking at the code.  Surely one wants more structure than that, or 
don't they have more structure?  This is exactly the kind of thing we are 
just talking about with the game theory code - we want a class because you 
want to *do* something with it.  Tab-completion rules!  But I suppose it's 
possible that all these designs really are just lists of lists.

Those are all the changes that are triggered if I have to use those cursed 
> objects where they don't belong.
>
>
I guess I don't know why they have to be immutable since not every class is 
immutable (is it?) but I will trust you on this.

>  (And ones that also don't use
> > "who_asked", a purely internal thing - that should be some internal
> > attribute, not a keyword.)  
>
> This keyword is used to break infinite recursions. If you see a way around 
> I am interested.
>
>
So there isn't some attribute it can set, like self._who_asked, to check 
this, with the same purpose?  Again, just asking, maybe the only way to 
break them is a keyword.  But it does look quite awkward; such things 
really shouldn't be exposed in the API.
 

> I don't mind the work if it makes sense. But having to pick a worse data 
> structure and having to generate useless objects just because you cannot 
> stand a syntax that the language allows really is bad work.
>
>
I don't know that I can't stand it, but just that Sage has typically not 
done this, so as to have an easier-to-parse API.  Certainly there are 
always exceptions, since we also (as you say) want to release stuff.
 

> Please don't consider sage/combinat/designs/ as part of the combinat/ code 
> :-P
>
>
I just went by directory structure :)

> It is still largely possible to refactor the code, especially the 
> functions that are available from the global namespace. And it can be 
> done easily as it is just about modifying "design_catalog.py" which is 
> rather independent from the coming tickets. 


> For the internals, many constructions in combinatorial designs are 
> recursive and complicated. So separating the existence from 
> construction means do an exact copy of the code. The boolean answer is 
> just intended to cut the actual construction (the object are rather 
> big). So we can not live with two functions. On the other hand, this 
> function can be hidden from the global namespace. 

I guess I'm just surprised you need two functions; why can't you have one 
(underscore?) function that both of them call?  That is what was surprising 
to me, if it really is an *exact* copy of the code?

> For the external, as Nathann already said, multiplying the namespace with 
> designs.orthogonal_array(k, n) 
> designs.orthogonal_array_existence(k, n) 
> designs.orthogonal_array_maximum_size(n) 
> looks ugly to me as there are many combinatorial designs on which you 
> would have the same. It might also be gathered with no cost as 
> designs.orthogonal_array.SOMETHING 
> Perhaps better, I am not sure. 

Maybe.  I guess I see an awful lot of such extra namespace stuff in many 
other parts of Sage, so it doesn't frighten me :)

> But it will be socially accepta

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[Volker Braun]

On Friday, June 6, 2014 6:35:01 PM UTC+1, vdelecroix wrote:
>
> Nevertheless, there is an intermediate solution which I proposed 
> recently in #16347 comment:12. Let me repeat it here. Instead of 
> returning an OA or a boolean we can write a function 
> "orthogonal_array_construction(k, n)" whose specification would be 
> "return a pair (f, args) such that f(*args) is an OA(k,n) or return 
> None if Sage has no idea how to build it". That way, even the internal 
> function would be clean. 
>
 
That is very similar to what I proposed in 
https://groups.google.com/d/msg/sage-devel/OPe5VJpBiB4/OswLwqsMJKcJ

You could also wrap the args in a closure, then you don't have to pass them 
around.

For the external, as Nathann already said, multiplying the namespace with 
>  designs.orthogonal_array(k, n) 
>  designs.orthogonal_array_existence(k, n) 
>  designs.orthogonal_array_maximum_size(n) 
> looks ugly to me as there are many combinatorial designs on which you 
> would have the same.
>

How about is_orthogonal_array_implemented(k,n) instead of the passive. 
Also, since Nathan said that orthogonal_array_maximum_size is not the 
correct nomenclature there might be a better name as well.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Error Building sage-6.2: Error installing package atlas-3.10.1.20140210

[Volker Braun]

Try the latest beta (see also #16345)



On Friday, June 6, 2014 3:20:41 AM UTC+1, nat wrote:
>
> I was trying to build sage on the new Samsung Chromebook 2. I am using 
> crouton with Ubuntu 12.04. I tried to build Sage in the home folder of my 
> chroot(?). I attached the log file described below: 
>
> 
> Error installing package atlas-3.10.1.20140210
> 
> Please email sage-devel (http://groups.google.com/group/sage-devel)
> explaining the problem and including the relevant part of the log file
>   /home/NAME/sage-6.2/logs/pkgs/atlas-3.10.1.20140210.log
> Describe your computer, operating system, etc.
> If you want to try to fix the problem yourself, *don't* just cd to
> /home/NAME/sage-6.2/local/var/tmp/sage/build/atlas-3.10.1.20140210 and 
> type 'make' or whatever is appropriate.
> Instead, the following commands setup all environment variables
> correctly and load a subshell for you to debug the error:
>   (cd '/home/NAME/sage-6.2/local/var/tmp/sage/build/atlas-3.10.1.20140210' 
> && '/home/NAME/sage-6.2/sage' --sh)
> When you are done debugging, you can type "exit" to leave the subshell.
> 
>
> Since I am uncertain which part is "relevant", and since I enjoyed all of 
> it, I just attached the whole thing. Let me know if this isn't right. Thank 
> you so much for your help. 
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[Vincent Delecroix]

Hello,

I think that I was the main reviewer of the module on
orthogonal_array, so I take part in responsability! But on the other
hand I know the code quite well and can answer to some of the design
decisions.

It is still largely possible to refactor the code, especially the
functions that are available from the global namespace. And it can be
done easily as it is just about modifying "design_catalog.py" which is
rather independent from the coming tickets.

For the internals, many constructions in combinatorial designs are
recursive and complicated. So separating the existence from
construction means do an exact copy of the code. The boolean answer is
just intended to cut the actual construction (the object are rather
big). So we can not live with two functions. On the other hand, this
function can be hidden from the global namespace.

Nevertheless, there is an intermediate solution which I proposed
recently in #16347 comment:12. Let me repeat it here. Instead of
returning an OA or a boolean we can write a function
"orthogonal_array_construction(k, n)" whose specification would be
"return a pair (f, args) such that f(*args) is an OA(k,n) or return
None if Sage has no idea how to build it". That way, even the internal
function would be clean.

For the external, as Nathann already said, multiplying the namespace with
 designs.orthogonal_array(k, n)
 designs.orthogonal_array_existence(k, n)
 designs.orthogonal_array_maximum_size(n)
looks ugly to me as there are many combinatorial designs on which you
would have the same. It might also be gathered with no cost as
 designs.orthogonal_array.SOMETHING
Perhaps better, I am not sure.

All best,
Vincent

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Error Building sage-6.2: Error installing package atlas-3.10.1.20140210

[nat]

I was trying to build sage on the new Samsung Chromebook 2. I am using 
crouton with Ubuntu 12.04. I tried to build Sage in the home folder of my 
chroot(?). I attached the log file described below: 


Error installing package atlas-3.10.1.20140210

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
  /home/NAME/sage-6.2/logs/pkgs/atlas-3.10.1.20140210.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/NAME/sage-6.2/local/var/tmp/sage/build/atlas-3.10.1.20140210 and type 
'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd '/home/NAME/sage-6.2/local/var/tmp/sage/build/atlas-3.10.1.20140210' 
&& '/home/NAME/sage-6.2/sage' --sh)
When you are done debugging, you can type "exit" to leave the subshell.


Since I am uncertain which part is "relevant", and since I enjoyed all of 
it, I just attached the whole thing. Let me know if this isn't right. Thank 
you so much for your help. 

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


atlas-3.10.1.20140210.log
Description: Binary data

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[Nathann Cohen]

Okay, I'm tired of this.

As soon as all the current patches are reviewed I will turn all this code
into socially acceptable Object-Oriented crap. It will be bad work, bad
decisions taken for bad reasons, but this will let me add actual
mathematical code to Sage later on while I cannot do this if every single
tickets takes days of fights.

You will be glad.

There will be a Parent named "OrthogonalArrays", another named
"TransversalDesigns", another named "MutuallyOthogonalLatinSquares". There
will be Elements, i.e. the actual orthogonal arrays, transversal designs
and mutually orthogonal latin squares.

They will all inherit the following totally useless (and broken) methods :
sage:
sage: Element.
Element.N Element.category  Element.dumps
  Element.n Element.renameElement.subs

Element.base_extend   Element.dbElement.is_zero
  Element.numerical_approx  Element.reset_nameElement.substitute

Element.base_ring Element.dump  Element.mro
  Element.parentElement.save  Element.version

There will also be a parent for all "Orthogonal Arrays of parameters
k=?,n=?". It will have a .an_element() method to return an actual design.
and a is_nonempty() function to know if it contains anything at all.

I don't know yet how to implement the "largest k such that there exists a
OA(k,n)" but I am pretty sure that a quite non-obvious
OrthogonalArrays(n=4).largest_k() would do the trick.

Of course, the actual orthogonal arrays, transversal designs, will need a
data structure. It will be immutable and as predicted above it will require
useless copies.

It will be FANTASTIC. Hundreds if not thousands of lines of code for
absolutely NO added feature. Objects creates and deallocated for absolutely
no point, possible memory leaks like the "cached method that returns
UniqueRepresentation objects" if I can manage it.

But it will be socially acceptable. It will be reviewed immediately because
it is what everybody accepts without even discussing the design.
I can't wait to be socially acceptable.

Nathann


On 6 June 2014 18:47, Nathann Cohen  wrote:

> > This is something fixable.  We deal with this in plotting and symbolics
> all
> > the time.  Naming things twice (esp. since orthogonal_array isn't in the
> > global namespace, just designs.[tab]) seems very reasonable to me.
> >
> > designs.orthogonal_array_maximum_size
> > designs.orthogonal_array_existence
>
> Okay let's be reasonable. The functions I would need are :
>
> designs.orthogonal_array_maximum_size # note that the terminology is not
> right
> designs.orthogonal_array_existence
> designs.orthogonal_array
> designs.transversal_design_maximum_size # same comment
> designs.transversal_design_existence
> designs.transversal_design
> designs.mutually_orthogonal_latin_squares_maximum_size # same comment
> designs.mutually_orthogonal_existence
> designs.mutually_orthogonal
>
> Of course, I would also needs 3 hidden function that would be called by
> the others
>
> _orthogonal_array_all_at_once
> _transversal_design_all_at_once
> _mutually_orthogonal_latin_squares_all_at_once
>
> Note that I would also need to triple MANY functions in the graph code,
> for the very reason that you insist on writing Python code as if it were C
> code.
>
>
> > Usually, in Sage, we have kept to a convention that such keywords do
> things
> > like try other algorithms or verify truth (as indeed in orthogonal_array
> in
> > Sage 6.2, where I though I saw a check keyword of some kind).  Naturally,
> > Python can do this, but it is helpful to keep things
>
> I have been doing this in the Graph code for years. And I think that I
> remember how it began :
>
> It was the early days of Linear Programming. I was writing functions to
> solve NP hard stuff, returning partitions of vertices or list of vertices,
> and though that perhaps I could save this with a "value_only" flag. When a
> graph function has such a flag, it means that it will not return the actual
> list of vertices, but its size instead.
>
> This, because in the optimization world, we deal with existence problems.
> And existence problems have what is called a "certificate", ie "some
> information which can be used to check, in polynomial time, that the answer
> given to the decision problem is right".
>
> Thus in the graph code you will have functions with a "certificate" flag,
> others with a "value_only" flag. And their output changes according to that.
>
> Python is *NOT* typed. Accept it.
>
> > Shell isn't Python.  In fact, you are losing the point of
> > object-orientedness.  Again, I'm sure Sage also does this in some places,
> > but over time it would be good to minimize those places.
>
> I think, on the other hand, that people are so used to object-oriented
> programming that they do not see when it is not a good idea anymore.
>
> I don't want to have to create objects that will be only used to access
> methods

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[Nathann Cohen]

> This is something fixable.  We deal with this in plotting and symbolics
all
> the time.  Naming things twice (esp. since orthogonal_array isn't in the
> global namespace, just designs.[tab]) seems very reasonable to me.
>
> designs.orthogonal_array_maximum_size
> designs.orthogonal_array_existence

Okay let's be reasonable. The functions I would need are :

designs.orthogonal_array_maximum_size # note that the terminology is not
right
designs.orthogonal_array_existence
designs.orthogonal_array
designs.transversal_design_maximum_size # same comment
designs.transversal_design_existence
designs.transversal_design
designs.mutually_orthogonal_latin_squares_maximum_size # same comment
designs.mutually_orthogonal_existence
designs.mutually_orthogonal

Of course, I would also needs 3 hidden function that would be called by the
others

_orthogonal_array_all_at_once
_transversal_design_all_at_once
_mutually_orthogonal_latin_squares_all_at_once

Note that I would also need to triple MANY functions in the graph code, for
the very reason that you insist on writing Python code as if it were C code.

> Usually, in Sage, we have kept to a convention that such keywords do
things
> like try other algorithms or verify truth (as indeed in orthogonal_array
in
> Sage 6.2, where I though I saw a check keyword of some kind).  Naturally,
> Python can do this, but it is helpful to keep things

I have been doing this in the Graph code for years. And I think that I
remember how it began :

It was the early days of Linear Programming. I was writing functions to
solve NP hard stuff, returning partitions of vertices or list of vertices,
and though that perhaps I could save this with a "value_only" flag. When a
graph function has such a flag, it means that it will not return the actual
list of vertices, but its size instead.

This, because in the optimization world, we deal with existence problems.
And existence problems have what is called a "certificate", ie "some
information which can be used to check, in polynomial time, that the answer
given to the decision problem is right".

Thus in the graph code you will have functions with a "certificate" flag,
others with a "value_only" flag. And their output changes according to that.

Python is *NOT* typed. Accept it.

> Shell isn't Python.  In fact, you are losing the point of
> object-orientedness.  Again, I'm sure Sage also does this in some places,
> but over time it would be good to minimize those places.

I think, on the other hand, that people are so used to object-oriented
programming that they do not see when it is not a good idea anymore.

I don't want to have to create objects that will be only used to access
methods.
If I create those objects, I will need to write a OrthogonalArray class, a
TransversalDesign class, and these objects (which, currently, are lists of
lists) will HAVE to be immutable.
If these objects are made immutable, I will NEED to copy them again and
again and again in all recursive constructions instead of changing them.

Those are all the changes that are triggered if I have to use those cursed
objects where they don't belong.

> Anyway, since all this new stuff is still in beta, is there a possibility
of
> refactoring this and making a few methods?

I have a lot of modification to do on these files, a lot of nice stuff to
add, but there are currently 9 patches in needs_review in the
combinatorial_designs section. I cannot add code not improve anything
unless the patches end up being reviewed.

>  (And ones that also don't use
> "who_asked", a purely internal thing - that should be some internal
> attribute, not a keyword.)

This keyword is used to break infinite recursions. If you see a way around
I am interested.

> I really really really really (!) understand that it would be a very
> annoying piece of work to do so.

I don't mind the work if it makes sense. But having to pick a worse data
structure and having to generate useless objects just because you cannot
stand a syntax that the language allows really is bad work.

> And I know it is, if not orthogonal, at
> least tangential to the question of cache functions.  But it would be so
so
> so good for Sage in the long term.  I know I am no expert software
engineer
> and make lots of dumb design choices, and of course much of the combinat
> code is largely not going to be used by me or my students or people I
teach
> Sage...

Please don't consider sage/combinat/designs/ as part of the combinat/ code
:-P

> but on the other hand if we have the chance to tighten things up, it
> seems reasonable to take the opportunity.

I have been walking in circles for days or weeks because the patches are
waiting for a review. I cannot write code for as long as there is stuff
still left to be reviwed.

Nathann

-- 
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...@googleg

Re: [sage-devel] Re: cached_function: a filter to only cache some inputs ?

[kcrisman]

I didn't watch this thread before, but now I'm sorry I didn't.
 

> > If
> > designs.orthogonal_array doesn't return some kind of array then it is 
> poorly
> > named. Use three different functions, e.g. orthogonal_array() /
> > is_constructible() / size_of_array()
> >
> > This basic design pattern also fixes your caching problem.
>
> Yes, but it duplicates the code horribly. Because orthogonal_array is a 
> long sequence of tests and answers,and you do not want to find this long 
> collection of tests and answers copied and pasted into three different 
> functions, nor to find out that "for some reason" they are not always 
> consistent with each other.
>
>
See below - that is precisely when that code should be abstracted out.
 

> More precisely :
>
> > designs.orthogonal_array doesn't return some kind of array then it is 
> poorly named
>
> No. Because if you want to build orthogonal arrays, you *will* find a 
> function named orthogonal_array. You may not find a function named 
> size_of_maximal_orthogonal_array.
>
>
This is something fixable.  We deal with this in plotting and symbolics all 
the time.  Naming things twice (esp. since orthogonal_array isn't in the 
global namespace, just designs.[tab]) seems very reasonable to me.

designs.orthogonal_array_maximum_size
designs.orthogonal_array_existence

and then take all the code that could be repeated and put it in a 'private' 
(underscore) function.  Again, this is something that happens a lot in 
various other parts of Sage.  

(Also, in this particular case there are very few commands to even find by 
tab-completion, so people in such a specialized research area will likely 
find them.  But of course this won't always obtain as an argument.)

By the way, I love how nobody has a problem with
>
> sage: designs.OrthogonalArray(4,3).exists()
> True
> sage: designs.OrthogonalArray(4,3).matrix()
> BigMatrix
>
>
because these are different methods, so it makes sense.
 

> while on the other hand
>
> sage: designs.orthogonal_array(4,3,existence=True)
> True
> sage: designs.orthogonal_array(4,3)
> BigMatrix
>
>
Usually, in Sage, we have kept to a convention that such keywords do things 
like try other algorithms or verify truth (as indeed in orthogonal_array in 
Sage 6.2, where I though I saw a check keyword of some kind).  Naturally, 
Python can do this, but it is helpful to keep things 

 

> is "clearly bad design". Come on guys, we write Python code ! The point is 
> not only to make our code dead slow, it is ALSO to use the advantages of 
> the language. Stop writing Java and C wrapped in Python ! Do you complain 
> when "wc -l" returns an integer and "wc" returns three integers and a 
> filename ? Do you prefer wc.complete_info() and 
> wc.just_the_number_of_lines() ?
>
>
Shell isn't Python.  In fact, you are losing the point of 
object-orientedness.  Again, I'm sure Sage also does this in some places, 
but over time it would be good to minimize those places.
++
Anyway, since all this new stuff is still in beta, is there a possibility 
of refactoring this and making a few methods?  (And ones that also don't 
use "who_asked", a purely internal thing - that should be some internal 
attribute, not a keyword.)  

I really really really really (!) understand that it would be a very 
annoying piece of work to do so.  And I know it is, if not orthogonal, at 
least tangential to the question of cache functions.  But it would be so so 
so good for Sage in the long term.  I know I am no expert software engineer 
and make lots of dumb design choices, and of course much of the combinat 
code is largely not going to be used by me or my students or people I teach 
Sage... but on the other hand if we have the chance to tighten things up, 
it seems reasonable to take the opportunity.

- kcrisman

>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Recommendations for a new Parent/Element pair

[Vincent Delecroix]

2014-06-06 17:12 UTC+02:00, Travis Scrimshaw :
> I don't think there's much documentation beyond what's in
> _coerce_map_from_() in Parent.
>
> If it returns re, then it uses _element_constructor_ to construct the
> morphism. Otherwise you return a morphism. I think there's some examples in
>
> src/algebras which returns morphisms (I'm pretty sure I've seen it,
> definitely wrote some code on it, but I don't remember off-hand for what).

Two other examples are ZZ -> QQ and QQ->ZZ which are respectively a
Morphism and a Map (see sage/rings/rational.pyx at the very end of the
file).

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Recommendations for a new Parent/Element pair

[Travis Scrimshaw]

I don't think there's much documentation beyond what's in 
_coerce_map_from_() in Parent.

If it returns re, then it uses _element_constructor_ to construct the 
morphism. Otherwise you return a morphism. I think there's some examples in 
src/algebras which returns morphisms (I'm pretty sure I've seen it, 
definitely wrote some code on it, but I don't remember off-hand for what).

Best,
Travis

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Seattle Questions

[William Stein]

On Jun 6, 2014 1:59 AM, "Martin Albrecht" 
wrote:
>
> On Thursday 05 Jun 2014 20:58:55 you wrote:
> > Do I need to book a hotel or can we stay at the house?
>
> You will need to book a hotel room, see:
>
>   https://groups.google.com/forum/#!topic/bugdays/FhB7gi1JY80
>
> You should also subscribe to that list to stay in the loop.
>
> > Is there anyone who could get me from the airport or do I need to take a
> > bus or something?
>
> You will need to arrange your own transportation from/to the airport. I
have
> no idea if that's reimbursed or not, though.
>

Yes it is reimbursed.

> Cheers,
> Martin

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Please review symbolic integration tickets

[Ralf Stephan]

Hello,
These tickets fix some long-standing problems with integration.

http://trac.sagemath.org/ticket/8734
http://trac.sagemath.org/ticket/16007

Please review.  Regards,

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Making the reference manual's introduction more concise

[Nathann Cohen]

> I did already. Not every review is to the positive %-)

This is not a review, this is trolling. Come on guy, the feature can
be useful ! Don't kill it because of something else which is already
done anyway !

Nathann

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Making the reference manual's introduction more concise

[Volker Braun]

On Friday, June 6, 2014 1:44:13 PM UTC+1, Nathann Cohen wrote:
>
> P.S. : Still not feeling like reviewing #16353 ? :-PPP
>

I did already. Not every review is to the positive %-) 

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Logs for aleph.sagemath.org

[Jason Grout]

On 6/5/14, 2:33, Ivan Andrus wrote:

Are there logs (and if so where are they?) for aleph.sagemath.org?  I'm trying 
to figure out what sorts of things the iOS app is used for.


Yes, there are logs.   Right now, we log remote ip, referer, execution 
type, kernel id, and the code text: 
https://github.com/sagemath/sagecell/blob/master/log.py


That's a good idea to log the user agent too, but we don't have 
historical data on that (at least from the ios app)


Thanks,

Jason



--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Making the reference manual's introduction more concise

[Nathann Cohen]

Yo !

> I agree.

O_O

God. This caught me off guard O_O

> Still, even with your branch the text starts with "This is the reference
manual". Well it better be since there is a big fat "Reference Manual"
headline.

I just pushed this :

---
This is a thematic index of all of `Sage's `_
features. It also contains many examples that illustrate their use, all of
them
systematically tested with each release.
---

> How about we move the whole text into a separate "Foreword" menu item.

I would say that it still does not belong to the reference manual, but
rather to the website or to some introductive document on Sage.

But given that I expected this thread to become another "one Vs everybody"
(happens a lot these days), I am so relieved that I am ready to agree with
everybody on absolutely everything :-P

Nathann

P.S. : Still not feeling like reviewing #16353 ? :-PPP

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Making the reference manual's introduction more concise

[Volker Braun]

I agree. Still, even with your branch the text starts with "This is the 
reference manual". Well it better be since there is a big fat "Reference 
Manual" headline.

How about we move the whole text into a separate "Foreword" menu item.





On Friday, June 6, 2014 1:19:24 PM UTC+1, Nathann Cohen wrote:
>
> Hello everybody !
>
> I was looking at http://www.sagemath.org/doc/reference/ while preparing a 
> short introductive talk to Sage aaand I thought that the "introduction" 
> to the reference manual missed the point a bit...
>
> What is says is good to be said, but I felt that it rather belong to 
> Sage's homepage or something, not to the reference manual.
>
> There is really a lot of text there, and I thought that we could make this 
> page more "to the point" by removing a bit of it. There are also two 
> paragraphs about the first two entries of the reference manual (they just 
> follow), aand it seemed really overkill.
>
> What do you think ?
>
> I created #16452 and branch public/16452 for that. Everybody's welcome to 
> add commits :-)
>
> Nathann
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Making the reference manual's introduction more concise

[Nathann Cohen]

(when the branch is applied : http://www.steinertriples.fr/ncohen/tmp/a.jpg)

Nathann


On 6 June 2014 14:19, Nathann Cohen  wrote:

> Hello everybody !
>
> I was looking at http://www.sagemath.org/doc/reference/ while preparing a
> short introductive talk to Sage aaand I thought that the "introduction"
> to the reference manual missed the point a bit...
>
> What is says is good to be said, but I felt that it rather belong to
> Sage's homepage or something, not to the reference manual.
>
> There is really a lot of text there, and I thought that we could make this
> page more "to the point" by removing a bit of it. There are also two
> paragraphs about the first two entries of the reference manual (they just
> follow), aand it seemed really overkill.
>
> What do you think ?
>
> I created #16452 and branch public/16452 for that. Everybody's welcome to
> add commits :-)
>
> Nathann
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Making the reference manual's introduction more concise

[Nathann Cohen]

Hello everybody !

I was looking at http://www.sagemath.org/doc/reference/ while preparing a
short introductive talk to Sage aaand I thought that the "introduction"
to the reference manual missed the point a bit...

What is says is good to be said, but I felt that it rather belong to Sage's
homepage or something, not to the reference manual.

There is really a lot of text there, and I thought that we could make this
page more "to the point" by removing a bit of it. There are also two
paragraphs about the first two entries of the reference manual (they just
follow), aand it seemed really overkill.

What do you think ?

I created #16452 and branch public/16452 for that. Everybody's welcome to
add commits :-)

Nathann

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Please review Python 2.7.6 update

[Volker Braun]

Bump

Note that ticket is now about Python 2.7.7 update

On Tuesday, June 3, 2014 10:32:57 PM UTC+1, François wrote:
>
> I am sorry, I don't think I have the foo for #16415 otherwise it would 
> have been done sometime ago. 
>
> Francois 
>
> On Tue, 03 Jun 2014 08:00:26 Volker Braun wrote: 
> > Just another data point that the review process for third-party packages 
> is 
> > broken... 
> > 
> > On Tuesday, June 3, 2014 3:13:18 PM UTC+1, William wrote: 
> > > On Jun 3, 2014 4:07 AM, "Volker Braun"  > 
> > > 
> > > wrote: 
> > > > bump 
> > > > 
> > > > On Saturday, May 31, 2014 1:36:26 PM UTC+1, Volker Braun wrote: 
> > > >> #16260: Python 2.7.6 
> > > 
> > > Python 2.7.7 was released already (I think yesterday). 
> > > 
> > > >> #16415: Ignore case in package directory 
> > > >> 
> > > >> http://trac.sagemath.org/ticket/16260 
> > > >> http://trac.sagemath.org/ticket/16415 
> > > 
> > > Groups "sage-devel" group. 
> > > 
> > > > To unsubscribe from this group and stop receiving emails from it, 
> send 
> > > 
> > > an email to sage-devel+...@googlegroups.com . 
> > > 
> > > > To post to this group, send email to sage-...@googlegroups.com 
> > > 
> > > . 
> > > 
> > > > Visit this group at http://groups.google.com/group/sage-devel. 
> > > > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Seattle Questions

[Martin Albrecht]

On Thursday 05 Jun 2014 20:58:55 you wrote:
> Do I need to book a hotel or can we stay at the house?

You will need to book a hotel room, see: 

  https://groups.google.com/forum/#!topic/bugdays/FhB7gi1JY80

You should also subscribe to that list to stay in the loop.

> Is there anyone who could get me from the airport or do I need to take a
> bus or something?

You will need to arrange your own transportation from/to the airport. I have 
no idea if that's reimbursed or not, though.

Cheers,
Martin

signature.asc
Description: This is a digitally signed message part.