I am trying to build sage-6.2 on FreeBSD. I get errors like the
following in sage-6.2/logs/pkgs/libgap-4.7.4.log
. lots of configure stuff .
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
Building libGAP...
make[3]
On Wed, 14 May 2014 06:57:53 Volker Braun wrote:
> On Wednesday, May 14, 2014 11:54:56 AM UTC+1, Thierry
>
> (sage-googlesucks@xxx) wrote:
> > In short, what is the git command to get a summary of the changes related
> > to a package
>
> git log build/pkgs/
>
> git trac find
>
I am guessing t
Hi Robert,
On 2014-05-14, Robert Bradshaw wrote:
> Another option is to do code generation, e.g. with one of the (many)
> Python templating libraries out there.
You mean some program will write Cython code for me, Cython will
write C code for me, and gcc will do the rest? Has this approach been
Hi,
thank you all for the support. the build of version 6.2 worked fine, and
also the topcom installation.
best regards
Oskar
On Wednesday, May 7, 2014 11:24:01 AM UTC+2, Oskar Till wrote:
>
> Just as I got my sage to work with topcom on my old laptop, I had to
> change computer. Installing
Another option is to do code generation, e.g. with one of the (many)
Python templating libraries out there.
On Wed, May 14, 2014 at 8:59 AM, Simon King wrote:
> Hi Martin,
>
> On 2014-05-14, Martin Albrecht wrote:
>> We've done some templating before when Cython didn't speak C++ so well and/or
>
Hi!
Nathann's original question/proposal was about ways to cache the return
value of a cached function only under specific conditions. This would
probably boil down to a decorator that takes more than one function as
argument. This is not unprecedented: Think of Python's @property.
So, I could ve
On Wednesday, May 14, 2014 4:59:49 PM UTC+1, leif wrote:
>
> Volker Braun wrote:
> > git trac find
>
> Does that work for the changes/commits whose changelog entries we're
> about to delete?
>
Not sure I understand, but probably "yes". Given the sha1 of the commit
that deletes somethnig, you
Y !!
> The answer is yes, and the solution is indeed wrapping as proposed, but
this can be done with less code repetition than I have seen on this thread
up to now:
Argg ! Of course !!! Well thought !!!
Well, there is an additional function between the two copies, and I would
nee
Or just add a thin wrapper is_possible which catch exceptions and cache the
boolean.
On Wednesday, May 14, 2014 5:51:10 PM UTC+2, Jean-Pierre Flori wrote:
>
>
>
> On Wednesday, May 14, 2014 5:09:18 PM UTC+2, Nathann Cohen wrote:
>>
>> > Or, if your code contains the is_prime_power() logic, just a
On Wednesday, May 14, 2014 3:54:36 AM UTC-7, Nathann Cohen wrote:
>
> I have a function named "a" which takes an integer as input. Unfortunately
> when 'n' is a prime power, a(n) returns a very large matrix (but quick to
> compute). Thus, I would love to cache only the answers of a(n) when n is
Volker Braun wrote:
git trac find
Does that work for the changes/commits whose changelog entries we're
about to delete?
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To un
Hi Martin,
On 2014-05-14, Martin Albrecht wrote:
> We've done some templating before when Cython didn't speak C++ so well and/or
> when C code was involved.
>
> 1. sage.rings.polynomials.polynomial_template provides a way to wrap
> univariate polynomials.
> ...
> 2. Matrix_modn_dense_template i
On Wednesday, May 14, 2014 5:09:18 PM UTC+2, Nathann Cohen wrote:
>
> > Or, if your code contains the is_prime_power() logic, just assign the
> > appropriate function (cached/non-cached) to some variable f and
> subsequently
> > call f() instead of a().
>
> I don't follow you
>
> Let us say
On Wednesday, May 14, 2014 4:12:41 PM UTC+1, Nathann Cohen wrote:
>
> @cached_function
>
def is_construction_possible(n):
> if whatever:
> return actual_construction #just the function
No, you haven't read what I wrote. In English, "is possible" asks for a
boolean outcome, so is
We've done some templating before when Cython didn't speak C++ so well and/or
when C code was involved.
1. sage.rings.polynomials.polynomial_template provides a way to wrap
univariate polynomials.
It is used by three classes:
polynomial_gf2x
polynomial_zmod_flint
polynomial_zz_pex
2. Matrix_m
William Stein wrote:
On May 13, 2014 7:13 PM, "François Bissey"
mailto:francois.bis...@canterbury.ac.nz>> wrote:
> It has been more or less done progressively as we touch the various spkg
> rather than a big swipe. I guess someone could try to do it in an
automated
> way.
A one-liner, see be
On Wednesday, May 14, 2014 5:09:11 PM UTC+2, Simon King wrote:
>
> Hi Jean-Pierre,
>
> On 2014-05-14, Jean-Pierre Flori > wrote:
> > Maybe use Cython C++ template support?
> > Note that recent Cython version even allows C++ template functions (and
> not
> > only classes/methods as before).
Hello !
> No, it does fix your caching problem. You can either cache the individual
> work_for_case_x or the is_constructible function.
>
> Just to be perfectly clear, the _select_case function does not perform any
> work! It only selects the function which would do the work if you were to
> c
> Or, if your code contains the is_prime_power() logic, just assign the
> appropriate function (cached/non-cached) to some variable f and
subsequently
> call f() instead of a().
I don't follow you
Let us say that I have a very complicated function a(), which builds
things, and that at some (l
Hi Jean-Pierre,
On 2014-05-14, Jean-Pierre Flori wrote:
> Maybe use Cython C++ template support?
> Note that recent Cython version even allows C++ template functions (and not
> only classes/methods as before).
In the cython version that is included in Sage? And is it possible to
write this in p
On Wednesday, May 14, 2014 3:45:06 PM UTC+1, Nathann Cohen wrote:
>
> Note that it changes nothing to my caching problem
>
No, it does fix your caching problem. You can either cache the
individual work_for_case_x or the is_constructible function.
Just to be perfectly clear, the _select_case func
"A cached function with selective memory"
http://trac.sagemath.org/ticket/16353
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...@go
On Wednesday, May 14, 2014 4:46:52 PM UTC+2, Simon King wrote:
>
> Hi!
>
> The topic of this post/request: Please share your knowledge about how
> to keep code duplication as small as possible when writing Cython code
> relying on several underlying implementations!
>
> In the Sage library, I
> So you need the caching because of potentially identical calls /in the
> recursion/?
There *will* be double-calls :-P
> If, so, first build a call graph and do CSE on it... ;-)
>
> Or, probably lazily evaluate the recursion tree.
Come on. This is exactly what cached functions are made
Hi!
The topic of this post/request: Please share your knowledge about how
to keep code duplication as small as possible when writing Cython code
relying on several underlying implementations!
In the Sage library, I have sometimes seen the following technique to
imitated templating with Cython:
1
Nathann Cohen wrote:
Similar answer as to your other thread:
Wrap the function, calling a cached function (also just a wrapper) if
existence=True, the bare function otherwise. Here the overhead is presumably
negligible.
Yesyes, but it really isn't pretty... :-/
It would be much better to h
> No. The tests of the work_for_case_x function go to that function. This
ties
> the tests much better to the implementation than what you currently have.
I agree with that and implemented it earlier but it was refused during a
review.
Note that it changes nothing to my caching problem, however.
On Wednesday, May 14, 2014 3:12:16 PM UTC+1, Nathann Cohen wrote:
>
> If I do that as in your example, then I have on one side the tests
> corresponding to each construction, and on the other side the
> functions corresponding to the tests
No. The tests of the work_for_case_x function go to tha
Nathann Cohen wrote:
Perhaps only slightly better (but omitting the additional 'cache_it'
parameter):
def a(n):
if n.is_prime_power():
return _a_noncached(n)
else:
return _a_cached(n)
@cached_function
def _a_cached(n):
return a_noncached(n)
(_a_noncached() is
> Implement the cases as functions:
If I do that as in your example, then I have on one side the tests
corresponding to each construction, and on the other side the
functions corresponding to the tests. And they are really tied
together, same thing here, I don't want to see them miles apart.
At s
Implement the cases as functions:
def work_for_case_1():
return long_computation_1()
def work_for_case_2():
return long_computation_2()
def _select_case():
if case1:
return work_for_case_1
elif case2:
return work_for_case_2
else:
raise NotImplementedError
On Wednesday, May 14, 2014 11:54:56 AM UTC+1, Thierry
(sage-googlesucks@xxx) wrote:
>
> In short, what is the git command to get a summary of the changes related
> to a package
git log build/pkgs/
git trac find
Various combinations could also be scripted but I don't really see the
need, ie.
> Well then go ahead and add a separate function for every distinct
> functionality. Then you don't need a hack to distinguish she way caching
> works.
Volker, we really have a LOT of places in the code which looks like that :
if case_1:
if existence:
return True
else:
do_
On Wednesday, May 14, 2014 12:21:24 PM UTC+1, Nathann Cohen wrote:
>
> > But the fact that it interacts badly with decorators should be a hint
> that my argument is true nevertheless.
>
> Why should it be ? We write functions, we update them, we change them
Well then go ahead and add a separat
On May 13, 2014 7:13 PM, "François Bissey"
wrote:
>
> On Tue, 13 May 2014 18:52:03 William Stein wrote:
> > On Tue, May 13, 2014 at 6:43 PM, François Bissey
> >
> > wrote:
> > > On Tue, 13 May 2014 18:30:26 William Stein wrote:
> > >> On Tue, May 13, 2014 at 6:23 PM, François Bissey
> > >>
> > >>
Yo !!
> Perhaps only slightly better (but omitting the additional 'cache_it'
> parameter):
>
> def a(n):
> if n.is_prime_power():
> return _a_noncached(n)
> else:
> return _a_cached(n)
>
> @cached_function
> def _a_cached(n):
> return a_noncached(n)
>
>
> (_a_no
Yooo !!
> Similar answer as to your other thread:
>
> Wrap the function, calling a cached function (also just a wrapper) if
> existence=True, the bare function otherwise. Here the overhead is presumably
> negligible.
Yesyes, but it really isn't pretty... :-/
It would be much better to
Nathann Cohen wrote:
Hell everybody !!!
If you play with the designs.orthogonal_array(k,n) function, you will
see that it returns three kinds of things :
1) A matrix (potentially big)
2) A boolean (telling you whether the matrix CAN be built)
3) An integer (telling you how large the mat
Nathann Cohen wrote:
Yoo !!
> Perhaps not the most elegant solution ;-), but I guess you could use an
> auxiliary cached function that throws its result instead of returning it
> in cases where you don't want to cache it...
Hmmm... Well, the only way I see to do that is :
def my_mai
Francois Bissey wrote:
Comments, especially about patches are still welcome. But a lot of stuff should
just go in the commit message.
"The" commit message, hopefully.
In short, what is the git command to get a summary of the changes related
to a package, with pointers to the related trac tic
Thierry wrote:
On Wed, May 14, 2014 at 01:43:24PM +1200, François Bissey wrote:
[...]
I know that the squashing of the changelog in the new style sage is
unpopular in some quarters but I am sticking to the official line.
I am not sure a hole in the documentation can serve as "the official
lin
Yoo !!
> Perhaps not the most elegant solution ;-), but I guess you could use an
> auxiliary cached function that throws its result instead of returning it
> in cases where you don't want to cache it...
Hmmm... Well, the only way I see to do that is :
def my_main_function_which_caches_no
Nathann Cohen wrote:
> I have a function named "a" which takes an integer as input.
> Unfortunately when 'n' is a prime power, a(n) returns a very large
> matrix (but quick to compute). Thus, I would love to cache only the
> answers of a(n) when n is NOT a prime power, which are smaller and
> take
Am 2014-05-14 12:54, schrieb Nathann Cohen:
> 2) If not, do you think that implementing this is a nice idea ? (I am
> worried of making the standard use case slower)
Yes, I would need this as well. So also my other posting in the thread
"cached_function: a filter to only cache some inputs ?"
Da
Am 2014-05-14 11:52, schrieb Nathann Cohen:
> Now, it would be COOL if this function could cache its boolean/integer
> answers (for we ask the same questions very often), but caching the
> matrices is a really (really) bad idea.
>
> The return type is determined by an argument of orthogonal_array,
Dear me, the subject appeared a few times when other packages were
changed and on discussion of the git workflow but this one seems to be
the straw that broke the camel's back.
On 14/05/2014, at 22:54, Thierry wrote:
> On Wed, May 14, 2014 at 01:43:24PM +1200, François Bissey wrote:
> [...]
>
> Yeah I know.. But I swear that it comes from the Mathematics
> behind Just look at the code of the steiner_quadruple_systems.py
> file. That's the math talking, and what it says is not pretty.
Or even the brand-new combinat/designs/database.py. It took me a week to
write, and it probably too
> I did, and I needed some eye bleach to wash out the 100-line long
> if/elif/elif/... ;-)
Yeah I know.. But I swear that it comes from the Mathematics
behind Just look at the code of the steiner_quadruple_systems.py
file. That's the math talking, and what it says is not pretty.
> But the f
On Wednesday, May 14, 2014 11:45:31 AM UTC+1, Nathann Cohen wrote:
>
> Volker, you should read the code, and then we discuss it.
>
I did, and I needed some eye bleach to wash out the 100-line long
if/elif/elif/... ;-)
> Just because you can (in Python) doesn't mean that its a good idea.
> Just
On Wednesday, May 14, 2014 6:51:23 PM UTC+8, Nathann Cohen wrote:
>
> > Ewww.
> >
> > By the way, sqrt("this was a string") (lower case) is slightly better,
> > as the answer sounds like Yoda speech.
>
> Indeed. We must patch it to cast everything into lower case first.
>
>
o.O
--
You r
On Wed, May 14, 2014 at 01:43:24PM +1200, François Bissey wrote:
[...]
> I know that the squashing of the changelog in the new style sage is
> unpopular in some quarters but I am sticking to the official line.
I am not sure a hole in the documentation can serve as "the official
line", could you
Helloo everybody !
This thread is obviously totally unrelated to the other one.
I have a function named "a" which takes an integer as input. Unfortunately
when 'n' is a prime power, a(n) returns a very large matrix (but quick to
compute). Thus, I would love to cache only the answers of a(n)
> Ewww.
>
> By the way, sqrt("this was a string") (lower case) is slightly better,
> as the answer sounds like Yoda speech.
Indeed. We must patch it to cast everything into lower case first.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
Hi Leif,
On 2014-05-14, leif wrote:
> Try
>
> sage: sqrt("This is a string")
>
> vs.
>
> sage: sqrt("This was a string")
Ewww.
By the way, sqrt("this was a string") (lower case) is slightly better,
as the answer sounds like Yoda speech.
Cheers,
Simon
--
You received this message because you
> Thats another red flag. If it doesn't fit on a screen break it up into
> separate function.
Volker, you should read the code, and then we discuss it. I just can't code
your conditionned reflexes.
> Its terrible. Misleading function name (doesn't return an array), not
> discoverable.
Not "disco
> ... which means that you should probably turn this long collection of
> tests and answers into a cached method, which is then called by the
> other methods. So, no code duplication.
?
This is precisely the function I want to turn into a cached function.
Nathann
--
You received this message b
Hi Nathann,
On 2014-05-14, Nathann Cohen wrote:
>> 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 co
On Wednesday, May 14, 2014 11:32:10 AM UTC+1, Nathann Cohen wrote:
>
> Yes, but it duplicates the code horribly. Because orthogonal_array is a
> long sequence of tests and answers
>
Thats another red flag. If it doesn't fit on a screen break it up into
separate function.
> Besides, this is pr
> 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
(Of course designs.OrthogonalArray(4,3) would return a
UniqueRepresentation object worth 10 or 20 bytes, and this stays
cached somewhe
Yo !
> Don't overload functions by return type. This is generally a bad idea.
Having general ideas is also a bad idea in general.
> 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_con
By "updated" I mean pull from the develop branch on trac and then do
make in SAGE_ROOT.
The "make distclean" followed by "make" solved the problem... but in
the future I would be happy to find a softer solution.
Thanks
Vincent
2014-05-14 10:29 UTC+02:00, Volker Braun :
> Defin "updated". Also, "
Don't overload functions by return type. This is generally a bad idea.
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 c
Nathann Cohen wrote:
now. Some of the code was of very dubious quality in my opinion. I
recall an email from one developer telling me he did not see much
point in testing much, as he would just fix bugs when reported !!!
Ahahahah :-D
Probably something more to laugh about (due to
>
> now. Some of the code was of very dubious quality in my opinion. I
> recall an email from one developer telling me he did not see much
> point in testing much, as he would just fix bugs when reported !!!
>
Ahahahah :-D
Nathann
--
You received this message because you are subscribed to
Hell everybody !!!
If you play with the designs.orthogonal_array(k,n) function, you will see
that it returns three kinds of things :
1) A matrix (potentially big)
2) A boolean (telling you whether the matrix CAN be built)
3) An integer (telling you how large the matrix can be)
Now, it wo
Defin "updated". Also, "make distclean && make"
On Wednesday, May 14, 2014 12:30:08 AM UTC+1, vdelecroix wrote:
>
> Actually, it is even worse : no python file of the Sage library has
> been byte-compiled...
>
> 2014-05-14 1:09 UTC+02:00, Vincent Delecroix
> <20100.d...@gmail.com>:
>
> > Hello
Feel free to write a patch if you care about it.
On Wednesday, May 14, 2014 2:52:03 AM UTC+1, William wrote:
>
> I'm no big fan of the SPKG.txt changelog, which always seemed
> redundant to me. But if we're going to officially get rid of them,
> why not just get rid of all of them at once?
>
>
My 6.3.beta1 does not behave this way (ubuntu 12.04).
John
On 14 May 2014 00:30, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Actually, it is even worse : no python file of the Sage library has
> been byte-compiled...
>
> 2014-05-14 1:09 UTC+02:00, Vincent Delecroix <20100.delecr...@g
http://trac.sagemath.org/ticket/16350
Please review.
Regards,
On Tuesday, May 13, 2014 9:51:17 PM UTC+2, Peter Bruin wrote:
>
> I started a patchbot based on 6.3.beta1, and the problem has unfortunately
> popped up again with the new setuptools version:
>
>
> http://patchbot.sagemath.org/log/16
François Bissey wrote:
The "official" line is the developer guide:
https://www.sagemath.org/doc/developer/packaging.html#the-spkg-txt-file
The only mention of the changelog is for old style spkg:
http://www.sagemath.org/doc/developer/packaging_old_spkgs.html#the-file-spkg-txt
Now, if you think t
70 matches
Mail list logo
