Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

[Dima Pasechnik]

On Sat, May 2, 2020 at 12:46 AM John H Palmieri  wrote:
>
> Did you mean 9.2? It's too late to add deprecations to 9.1, in my opinion.
>

be it 9.1 or 9.2, it's certainly a good idea to deprecate and remove.

>
> On Friday, May 1, 2020 at 2:19:32 PM UTC-7, Matthias Koeppe wrote:
>>
>> These modules have a very limited amount of code, seem to have seen no major 
>> development for about 10 years, and are (with minor exceptions) unused in 
>> the rest of Sage.
>>
>> Potential users will be better off with looking for mainstream libraries in 
>> the Python ecosystem, or with interfacing with Python, etc.
>>
>>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/7fd459a4-2f42-413b-9e17-6075b50388ec%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0TB7yEE3GiEB8Bp57a0gSCZ40fMHamLgR1SjZEGyEu-Q%40mail.gmail.com.

[sage-devel] Re: Want to add generalised Newton's method for solving a nonlinear systems of equations to Sage

[jplab]

Hello Daniel,

I am not very familiar with the numerical newton methods in Sage. Have you 
looked in numpy?

Concerning the contribution process, you may appreciate the following 
answer given on AskSage

https://ask.sagemath.org/question/50630/how-to-contribute-to-sage-in-less-than-20-easy-steps/

which complements the Developers Manual:

https://doc.sagemath.org/html/en/developer/

Best,
J-P

Le samedi 2 mai 2020 00:09:34 UTC+2, Daniel Khodabakhsh a écrit :
>
> Hello,
>
> I have a generalised implementation of Newton's method for solving a 
> nonlinear system of equations that I want to add to Sage.
> This would be my first potential contribution so I had a few questions 
> before I can move forward.
>
> Questions #1:
> The reason I wrote an implementation was because I couldn't find this 
> algorithm in Sage. Before I proceed, could someone confirm that this indeed 
> doesn't already exist?
>
> Questions #2:
> If it really isn't part of Sage yet, which module should I add this to?
>
> Once I get this information I'll work on integrating it into the 
> recommended module and create a new ticket on https://trac.sagemath.org/
>
> If I have the process wrong please let me know!
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d7cc7821-3359-4462-b127-a479f8dc2bce%40googlegroups.com.

Re: [sage-devel] Re: Want to add generalised Newton's method for solving a nonlinear systems of equations to Sage

[Thierry Dumont]

Hello,

The question is : what sort of problem do you want to solve ? with what
method ?

Is this a pure Newton-(Raphson) method?

A) If yes:
 1) If you compute in RDF floats (that is: your machine floating points
  numbers, aka "double" in C), the best you have to do is to use the
scipy implementation, and hope (like always with Newton method) that it
will converge. It will also be slow, because the F and DF functions will
be coded in pure python (maybe, this will not be a problem if you want
to solve small problems). I think there is no need to add a new method
for RDF. May be creating an optimized method (using cython ?) could be
interesting.

See:
https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.newton.html
for the scipy implementation.

 2) If you want to compute in an other set of numbers, there is nothing
(as far as I know) in Sage. For example, the Newton method can be
implemented un interval arithmetic (RealIntervalField or RealBallField).
But implementing something a bit generic is certainly not so easy.

B) If no:
That is to say you are interested by implementing a generalized Newton,
or quasi Newton method, something like that...
These methods are very specialized, and I am not sure it will be an
useful tool. But I can be wrong.

Yours,

Thierry.



Le 02/05/2020 à 00:28, Daniel Khodabakhsh a écrit :
> Sorry forgot to give details on the algorithm I want to add.
> 
> Here's a Wikipedia link o
> n
> the subject.
> 
> To summarise, it's an iterative numerical method, similar
> to sage.numerical.optimize.find_root
> 
>  but
> whose usage would be closer to sage.symbolic.relation.solve
> .
> 
> Not sure if google groups supports LaTeX but here's a try:
> $$x_{n+1} = x_{n} - J_F(x_n)^{-1}F(x_n)$$
> 
> On Friday, May 1, 2020 at 3:09:34 PM UTC-7, Daniel Khodabakhsh wrote:
> 
> Hello,
> 
> I have a generalised implementation of Newton's method for solving a
> nonlinear system of equations that I want to add to Sage.
> This would be my first potential contribution so I had a few
> questions before I can move forward.
> 
> Questions #1:
> The reason I wrote an implementation was because I couldn't find
> this algorithm in Sage. Before I proceed, could someone confirm that
> this indeed doesn't already exist?
> 
> Questions #2:
> If it really isn't part of Sage yet, which module should I add this to?
> 
> Once I get this information I'll work on integrating it into the
> recommended module and create a new ticket on https://trac.sagemath.org/
> 
> If I have the process wrong please let me know!
> 
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/cd1aa005-abcb-4fcb-a436-5afaac4739a0%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a58ed617-9694-1c4d-1ea7-02822fc64832%40math.univ-lyon1.fr.
<>

Re: [sage-devel] remove log_html() and other log_*()

[Michael Orlitzky]

On 5/1/20 1:36 PM, John H Palmieri wrote:
> 
> So before deprecating, consider points of view of users from different
> backgrounds. We hope that mathematicians are using Sage, and we
> shouldn't require them to know about "grep". Don't get me wrong, grep is
> great and I use it all the time, but I bet that many of my colleagues
> don't know it, don't want to learn the syntax, and would view '!grep -R
> -n ... "$SAGE_ROOT"/src/sage' as an essentially magical incantation. I
> think that 'search_src(...)' is more accessible.
> 

This doesn't have to involve an incantations at all. Grep is already
there (and superior) for anyone who wants to use one, but you're free to
open up a GUI file manager, browse to the sage directory, click a few
things on a drop-down menu, and ask it to search for your string that
way. That's another relatively reusable skill that many people already
know and that solves the same problem on any platform. Grep is really
just a special case of that, "do whatever you would normally do to
search for files containing a string."

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/75dfdd7a-dc52-33e6-7a6d-85243a19a2d2%40orlitzky.com.

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

[Sébastien Labbé]

At least, I know that module sage/finance/stock.py is completely broken. A 
warning was added in trac ticket #25473  
in the top of the page of 
http://doc.sagemath.org/html/en/reference/finance/sage/finance/stock.html
For the doctests to pass, tag "known bug" was added for most of the 
doctests:

$ sage -t --optional=sage,internet --show-skipped src/sage/finance/stock.py
...
22 tests not run due to known bugs
...

I don't use any of these three modules, but maybe some do? The stats folder 
contains a lot of stuff:

$ tree stats/
stats/
├── all.py
├── basic_stats.py
├── distributions
│   ├── dgs_bern.c
│   ├── dgs_bern.h
│   ├── dgs_gauss_dp.c
│   ├── dgs_gauss.h
│   ├── dgs_gauss_mp.c
│   ├── dgs.h
│   ├── dgs_misc.h
│   ├── dgs.pxd
│   ├── discrete_gaussian_integer.pxd
│   ├── discrete_gaussian_integer.pyx
│   ├── discrete_gaussian_lattice.py
│   ├── discrete_gaussian_polynomial.py
│   ├── __init__.py
│   └── __pycache__
├── hmm
│   ├── all.py
│   ├── chmm.pyx
│   ├── distributions.pxd
│   ├── distributions.pyx
│   ├── hmm.pxd
│   ├── hmm.pyx
│   ├── __init__.py
│   ├── __pycache__
│   ├── util.pxd
│   └── util.pyx
├── __init__.py
├── intlist.pxd
├── intlist.pyx
├── __pycache__
└── r.py

5 directories, 28 files
$ tree finance/
finance/
├── all.py
├── easter.py
├── fractal.pyx
├── __init__.py
├── markov_multifractal_cython.pyx
├── markov_multifractal.py
├── option.pyx
├── __pycache__
├── stock.py
├── time_series.pxd
└── time_series.pyx

1 directory, 10 files
$ tree media/
media/
├── all.py
├── channels.pyx
├── __init__.py
├── __pycache__
└── wav.py

1 directory, 4 files


On Saturday, May 2, 2020 at 9:56:18 AM UTC+2, Dima Pasechnik wrote:
>
> On Sat, May 2, 2020 at 12:46 AM John H Palmieri  > wrote: 
> > 
> > Did you mean 9.2? It's too late to add deprecations to 9.1, in my 
> opinion. 
> > 
>
> be it 9.1 or 9.2, it's certainly a good idea to deprecate and remove. 
>
> > 
> > On Friday, May 1, 2020 at 2:19:32 PM UTC-7, Matthias Koeppe wrote: 
> >> 
> >> These modules have a very limited amount of code, seem to have seen no 
> major development for about 10 years, and are (with minor exceptions) 
> unused in the rest of Sage. 
> >> 
> >> Potential users will be better off with looking for mainstream 
> libraries in the Python ecosystem, or with interfacing with Python, etc. 
> >> 
> >> 
> > -- 
> > 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-...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/7fd459a4-2f42-413b-9e17-6075b50388ec%40googlegroups.com.
>  
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a0af1eff-9f31-45d8-84d4-e6d1a6c6eb2a%40googlegroups.com.

[sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Julien Puydt]

Hi,

I'm maintaining pynac in Debian, with the goal of keeping sagemath
packaged in Debian.

According to :
https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop

the version in sage is now 0.7.26.sage-2020-04-03, while upstream is
0.7.26.

Is there some patch I could add to the Debian packaging? Did it go
through upstream for approval? I had a look around and didn't find the
information...

Cheers,

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4dda6e5fc43971bcbf7349263c01c52de90b7034.camel%40gmail.com.

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Dima Pasechnik]

On Sat, May 2, 2020 at 1:41 PM Julien Puydt  wrote:
>
> Hi,
>
> I'm maintaining pynac in Debian, with the goal of keeping sagemath
> packaged in Debian.
>
> According to :
> https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop
>
> the version in sage is now 0.7.26.sage-2020-04-03, while upstream is
> 0.7.26.
>
> Is there some patch I could add to the Debian packaging? Did it go
> through upstream for approval? I had a look around and didn't find the
> information...

upstream said to be too busy with COVID-19 - related research project ATM.
Thus, we rolled a new version ourselves.

HTH
Dima

>
> Cheers,
>
> JP
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/4dda6e5fc43971bcbf7349263c01c52de90b7034.camel%40gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2yd%3De%3DPUdFcF%3DMOP%3Dvcg0c9QPVoNo%3D02E8rL8qk8XfCA%40mail.gmail.com.

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Dima Pasechnik]

On Sat, May 2, 2020 at 1:58 PM Dima Pasechnik  wrote:
>
> On Sat, May 2, 2020 at 1:41 PM Julien Puydt  wrote:
> >
> > Hi,
> >
> > I'm maintaining pynac in Debian, with the goal of keeping sagemath
> > packaged in Debian.
> >
> > According to :
> > https://git.sagemath.org/sage.git/tree/build/pkgs/pynac/package-version.txt?h=develop
> >
> > the version in sage is now 0.7.26.sage-2020-04-03, while upstream is
> > 0.7.26.
> >
> > Is there some patch I could add to the Debian packaging? Did it go
> > through upstream for approval? I had a look around and didn't find the
> > information...
>
> upstream said to be too busy with COVID-19 - related research project ATM.
> Thus, we rolled a new version ourselves.
>

you can recreate  a patch from https://github.com/mkoeppe/pynac/releases

> HTH
> Dima
>
> >
> > Cheers,
> >
> > JP
> >
> > --
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sage-devel/4dda6e5fc43971bcbf7349263c01c52de90b7034.camel%40gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2tFvir2rgH_qFtJTyM9-RinLVvzE5GByYewYH071pgEA%40mail.gmail.com.

Re: [sage-devel] remove log_html() and other log_*()

[kcrisman]

On Saturday, May 2, 2020 at 7:12:42 AM UTC-4, Michael Orlitzky wrote:
>
> On 5/1/20 1:36 PM, John H Palmieri wrote: 
> > 
> > So before deprecating, consider points of view of users from different 
> > backgrounds. We hope that mathematicians are using Sage, and we 
> > shouldn't require them to know about "grep". Don't get me wrong, grep is 
> > great and I use it all the time, but I bet that many of my colleagues 
> > don't know it, don't want to learn the syntax, and would view '!grep -R 
> > -n ... "$SAGE_ROOT"/src/sage' as an essentially magical incantation. I 
> > think that 'search_src(...)' is more accessible. 
> > 
>
> This doesn't have to involve an incantations at all. Grep is already 
> there (and superior) for anyone who wants to use one, but you're free to 
> open up a GUI file manager, browse to the sage directory, 


You've already lost any Sage user who doesn't understand the structure of 
Sage, e.g. someone using it only through a notebook.

 

> click a few 
> things on a drop-down menu, and ask it to search for your string that 
> way. That's another relatively reusable skill that many people already 
> know and that solves the same problem on any platform. Grep is really 
> just a special case of that, "do whatever you would normally do to 
> search for files containing a string." 
>

I'm not sure that the sort of user we are talking about would think of 
"search for files containing a string".  Ideally we are attracting users 
who don't know what a string is at all, but want to get some math done. 
 Eventually, yes, for power usage you would want to know that, but to start 
you can just ape the commands, and later learn that there is a special type 
of Python thingie in quotes called a string - and learn the difference 
between raw strings and so forth.

Also, search_def is the one I found most useful when learning Sage 
properly, and the GUI manager method requires people to know the "def" is 
the word, not "definition" or even "function" or whatever.

It's fine if there is a platform-consistent better way to implement it with 
some sort of alias.  But it seems perverse to remove something useful, 
FINDABLE BY TAB COMPLETION, and instead make people learn to use these 
other, more tedious or more arcane, methods, when it already exists.  It 
would be sort of like removing a "help()" command in some other program 
because there is some other way the system can find help files which a 
power user should know, and which we could bury in documentation somewhere. 
 

That's fine for a dedicated user, but one would hope Sage would continue to 
support even the least dedicated user.  The mission statement would 
indicate we want to.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/44436910-8bd3-44d4-859f-8179f3ead119%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Michael Orlitzky]

On 5/2/20 9:20 AM, kcrisman wrote:
> 
> Also, search_def is the one I found most useful when learning Sage
> properly, and the GUI manager method requires people to know the "def"
> is the word, not "definition" or even "function" or whatever.
> 

Learning the word "def" is no harder than learning the word
"search_def," and again, the former is at least reusable knowledge.

I'll stop beating the dead horse; but I think we're catering to a user
with a highly peculiar set of disabilities.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e64d4689-5ff4-0cff-e3a6-63ba795d1811%40orlitzky.com.

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

[Vincent Delecroix]

If anything is broken, removing is fine with me.

Otherwise, *each* class/function in each of these modules must
be endowed with a very explicit deprecation warning pointing to
the better upstream equivalent. I do not see why there should be
any exception with our deprecation policy.

Le 02/05/2020 à 14:15, Sébastien Labbé a écrit :

At least, I know that module sage/finance/stock.py is completely broken. A
warning was added in trac ticket #25473 
in the top of the page of
http://doc.sagemath.org/html/en/reference/finance/sage/finance/stock.html
For the doctests to pass, tag "known bug" was added for most of the
doctests:

$ sage -t --optional=sage,internet --show-skipped src/sage/finance/stock.py
...
 22 tests not run due to known bugs
...

I don't use any of these three modules, but maybe some do? The stats folder
contains a lot of stuff:

$ tree stats/
stats/
├── all.py
├── basic_stats.py
├── distributions
│   ├── dgs_bern.c
│   ├── dgs_bern.h
│   ├── dgs_gauss_dp.c
│   ├── dgs_gauss.h
│   ├── dgs_gauss_mp.c
│   ├── dgs.h
│   ├── dgs_misc.h
│   ├── dgs.pxd
│   ├── discrete_gaussian_integer.pxd
│   ├── discrete_gaussian_integer.pyx
│   ├── discrete_gaussian_lattice.py
│   ├── discrete_gaussian_polynomial.py
│   ├── __init__.py
│   └── __pycache__
├── hmm
│   ├── all.py
│   ├── chmm.pyx
│   ├── distributions.pxd
│   ├── distributions.pyx
│   ├── hmm.pxd
│   ├── hmm.pyx
│   ├── __init__.py
│   ├── __pycache__
│   ├── util.pxd
│   └── util.pyx
├── __init__.py
├── intlist.pxd
├── intlist.pyx
├── __pycache__
└── r.py

5 directories, 28 files
$ tree finance/
finance/
├── all.py
├── easter.py
├── fractal.pyx
├── __init__.py
├── markov_multifractal_cython.pyx
├── markov_multifractal.py
├── option.pyx
├── __pycache__
├── stock.py
├── time_series.pxd
└── time_series.pyx

1 directory, 10 files
$ tree media/
media/
├── all.py
├── channels.pyx
├── __init__.py
├── __pycache__
└── wav.py

1 directory, 4 files


On Saturday, May 2, 2020 at 9:56:18 AM UTC+2, Dima Pasechnik wrote:


On Sat, May 2, 2020 at 12:46 AM John H Palmieri > wrote:


Did you mean 9.2? It's too late to add deprecations to 9.1, in my

opinion.




be it 9.1 or 9.2, it's certainly a good idea to deprecate and remove.



On Friday, May 1, 2020 at 2:19:32 PM UTC-7, Matthias Koeppe wrote:


These modules have a very limited amount of code, seem to have seen no

major development for about 10 years, and are (with minor exceptions)
unused in the rest of Sage.


Potential users will be better off with looking for mainstream

libraries in the Python ecosystem, or with interfacing with Python, etc.




--
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-...@googlegroups.com .

To view this discussion on the web visit

https://groups.google.com/d/msgid/sage-devel/7fd459a4-2f42-413b-9e17-6075b50388ec%40googlegroups.com.






--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c98698f2-845a-b116-f0f5-78f39b3d9da8%40gmail.com.

Re: [sage-devel] remove log_html() and other log_*()

[Sébastien Labbé]

> I feel the same way about functions like search_src() that badly 
> reimplement grep (even if they still work). 
>

I am fine with getting rid of the log_* functions, but I definitively want 
search_src(), search_def() and search_doc() to stay. Shame on me, but I use 
them when I need from the sage command line as well as the `sage -grep` 
instead of grep when I want to search the sage source from *any* directory 
on my computer.

For the same reason, I must also admit that I use some alias in my .bashrc 
file and I also define names that I can remember in .ssh/config file 
instead of ip adresses of servers which I just can't remember by heart :)

Sébastien

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/55898bde-8471-4c40-8da7-4d245df97a49%40googlegroups.com.

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Julien Puydt]

Hi,

Le samedi 02 mai 2020 à 14:03 +0100, Dima Pasechnik a écrit :
> 
> you can recreate  a patch from 
> https://github.com/mkoeppe/pynac/releases
> 

indeed :

https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03

and it shows :
- cygwin patches ;
- modifications for Python detection ;

all of which shouldn't make the pynac in Debian insuitable for sagemath
use.

Thanks!

JP

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/df120b572b4a3cc2aea15101596cdddab092850e.camel%40gmail.com.

Re: [sage-devel] remove log_html() and other log_*()

[John H Palmieri]

On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>
>
> I feel the same way about functions like search_src() that badly 
>> reimplement grep (even if they still work). 
>>
>
> I am fine with getting rid of the log_* functions, but I definitively want 
> search_src(), search_def() and search_doc() to stay. Shame on me, but I use 
> them when I need from the sage command line as well as the `sage -grep` 
> instead of grep when I want to search the sage source from *any* directory 
> on my computer.
>

OMG, why does "sage -grep" use the "find" command?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/03e185ca-398a-4c76-aaba-2056b69ab01d%40googlegroups.com.

Re: [sage-devel] What is pynac 0.7.26.sage-2020-04-03 ?

[Matthias Koeppe]

On Saturday, May 2, 2020 at 10:28:52 AM UTC-7, Julien Puydt wrote:
>
>
> indeed : 
>
>
> https://github.com/pynac/pynac/compare/pynac-0.7.26...mkoeppe:pynac-0.7.26.sage-2020-04-03
>  
>
> and it shows : 
> - cygwin patches ; 
> - modifications for Python detection ; 
>
> all of which shouldn't make the pynac in Debian insuitable for sagemath 
> use. 
>
>
That's right.

By the way, the new upstream_url field in build/pkgs/pynac/checksums.ini
tells you where this tarball came from:

 
upstream_url=https://github.com/mkoeppe/pynac/releases/download/pynac-VERSION/pynac-VERSION.tar.bz2


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5e2e482d-915b-4c8e-8099-eb73653d86b4%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Matthias Koeppe]

On Saturday, May 2, 2020 at 10:55:25 AM UTC-7, John H Palmieri wrote:
>
>
> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>>
>> I am fine with getting rid of the log_* functions, but I definitively 
>>> want search_src(), search_def() and search_doc() to stay. Shame on me, but 
>>> I use them when I need from the sage command line as well as the `sage 
>>> -grep` instead of grep when I want to search the sage source from *any* 
>>> directory on my computer.
>>>
>>
> OMG, why does "sage -grep" use the "find" command?
>
> The answer is probably something like "Solaris 7 grep does not accept -r"


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/602d2d75-800c-498e-af12-2efd3980ec79%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Dima Pasechnik]

On Sat, May 2, 2020 at 7:16 PM Matthias Koeppe  wrote:
>
> On Saturday, May 2, 2020 at 10:55:25 AM UTC-7, John H Palmieri wrote:
>>
>>
>> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:

 I am fine with getting rid of the log_* functions, but I definitively want 
 search_src(), search_def() and search_doc() to stay. Shame on me, but I 
 use them when I need from the sage command line as well as the `sage 
 -grep` instead of grep when I want to search the sage source from *any* 
 directory on my computer.
>>
>>
>> OMG, why does "sage -grep" use the "find" command?
>>
> The answer is probably something like "Solaris 7 grep does not accept -r"
HP-UX grep surely does not.

>
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/602d2d75-800c-498e-af12-2efd3980ec79%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0%3DE%2Bqhoq1ah0PQo8SwxwKC57n-7PBeUkdnFJbRFqk4NQ%40mail.gmail.com.

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

[Matthias Koeppe]

On Saturday, May 2, 2020 at 9:02:05 AM UTC-7, vdelecroix wrote:
>
> If anything is broken, removing is fine with me. 
>
> Otherwise, *each* class/function in each of these modules must 
> be endowed with a very explicit deprecation warning pointing to 
> the better upstream equivalent. I do not see why there should be 
> any exception with our deprecation policy. 
>
>
I agree with both of these points.

And yes, I guess I meant to suggest doing this for 9.2, right after 9.1 is 
released.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/66486477-19a1-45dd-898b-31bd694849f0%40googlegroups.com.

Re: [sage-devel] Re: Proposal: Deprecate all of sage.finance, sage.media, sage.stats in 9.1

[Matthias Koeppe]

On Saturday, May 2, 2020 at 11:23:34 AM UTC-7, Matthias Koeppe wrote:
>
>  I meant to suggest doing this for 9.2, right after 9.1 is released.
>

I have added a link to this thread to 
https://wiki.sagemath.org/ReleaseTours/sage-9.2

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f4dadaad-6290-4096-9b4e-003b95637b78%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Sébastien Labbé]

On Saturday, May 2, 2020 at 7:55:25 PM UTC+2, John H Palmieri wrote:
>
>
>
> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>>
>>
>> I feel the same way about functions like search_src() that badly 
>>> reimplement grep (even if they still work). 
>>>
>>
>> I am fine with getting rid of the log_* functions, but I definitively 
>> want search_src(), search_def() and search_doc() to stay. Shame on me, but 
>> I use them when I need from the sage command line as well as the `sage 
>> -grep` instead of grep when I want to search the sage source from *any* 
>> directory on my computer.
>>
>
> OMG, why does "sage -grep" use the "find" command?
>

I don't know, but just to mention that `sage -grep` can also be called as 
`sage -search_src` which is the equivalent of search_src() from the command 
line.

$ sage -advanced
...
  -search_src  -- search through all the Sage library code for 
string
  -search_doc  -- search through the Sage documentation for string
  -grep   -- same as -search_src
  -grepdoc-- same as -search_doc
...
 

 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/19ffa86d-4aa9-4580-a99a-caa0b13b2f68%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[John H Palmieri]

On Saturday, May 2, 2020 at 11:37:57 AM UTC-7, Sébastien Labbé wrote:
>
>
>
> On Saturday, May 2, 2020 at 7:55:25 PM UTC+2, John H Palmieri wrote:
>>
>>
>>
>> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>>>
>>>
>>> I feel the same way about functions like search_src() that badly 
 reimplement grep (even if they still work). 

>>>
>>> I am fine with getting rid of the log_* functions, but I definitively 
>>> want search_src(), search_def() and search_doc() to stay. Shame on me, but 
>>> I use them when I need from the sage command line as well as the `sage 
>>> -grep` instead of grep when I want to search the sage source from *any* 
>>> directory on my computer.
>>>
>>
>> OMG, why does "sage -grep" use the "find" command?
>>
>
> I don't know, but just to mention that `sage -grep` can also be called as 
> `sage -search_src` which is the equivalent of search_src() from the command 
> line.
>
> $ sage -advanced
> ...
>   -search_src  -- search through all the Sage library code for 
> string
>   -search_doc  -- search through the Sage documentation for string
>   -grep   -- same as -search_src
>   -grepdoc-- same as -search_doc
> ...
>

And search_src (etc.) used to be implemented with a combination of find and 
grep, just like sage -grep now. It was reimplemented in Python to make it 
work across platforms (because of differences in grep syntax, for example) 
and to make it faster (true story! see #6429).

If anyone has any interest in developing Sage for Solaris or other 
platforms whose grep doesn't support "-r", this is another reason to keep 
search_src, etc.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3a94c844-2d51-4d38-80dd-64b6d6e8dd82%40googlegroups.com.