On Friday, May 8, 2020 at 3:03:46 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Friday, May 8, 2020 at 2:17:25 PM UTC-7, Michael Orlitzky wrote:
>
>>
>> There are some duplicates in there (I've wasted enough time on it), but
>> it matches things that a regex never will. That function is implemented
On Friday, May 8, 2020 at 2:17:25 PM UTC-7, Michael Orlitzky wrote:
>
> There are some duplicates in there (I've wasted enough time on it), but
> it matches things that a regex never will. That function is implemented
> by the following code, which belongs in a third-party library and not
>
On 5/8/20 4:12 PM, Nils Bruin wrote:
> On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>
> I feel the same way about functions like search_src() that badly
> reimplement grep (even if they still work).
>
>
> I'm definitely in favour of keeping search_src and
On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>
> I feel the same way about functions like search_src() that badly
> reimplement grep (even if they still work).
>
I'm definitely in favour of keeping search_src and search_def. I find it
*super* convenient to not have
On 5/8/20 12:59 PM, John H Palmieri wrote:
>
> As a topologist, I would have to say that the best results are the ones
> for simplicial complexes and simplicial sets, actually.
>
Good news: those are also in my top five results. Bad news (?): Google
probably knows enough about you to put them in
On Friday, May 8, 2020 at 9:51:34 AM UTC-7, Michael Orlitzky wrote:
>
> On 5/8/20 12:11 PM, John H Palmieri wrote:
> >
> > They accomplish different things: one searches the global name space and
> > the other searches the source code.
> >
> > Example: can Sage compute any fundamental
On 5/8/20 12:11 PM, John H Palmieri wrote:
>
> They accomplish different things: one searches the global name space and
> the other searches the source code.
>
> Example: can Sage compute any fundamental groups?
>
Neither approach returns the best result. Putting
site:doc.sagemath.org
On Friday, May 8, 2020 at 3:08:21 AM UTC-7, Dima Pasechnik wrote:
>
> On Fri, May 8, 2020 at 10:37 AM Markus Wageringel
> > wrote:
> >
> > Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
> >>
> >> But if we talk about users who are not interested in code and strings,
>
On Friday, May 8, 2020 at 11:37:03 AM UTC+2, Markus Wageringel wrote:
>
> Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
>>
>> But if we talk about users who are not interested in code and strings,
>> wouldn't it be more useful for them to have a function that searches
>>
On Fri, May 8, 2020 at 10:37 AM Markus Wageringel
wrote:
>
> Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
>>
>> But if we talk about users who are not interested in code and strings,
>> wouldn't it be more useful for them to have a function that searches through
>> the global
Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
>
> But if we talk about users who are not interested in code and strings,
> wouldn't it be more useful for them to have a function that searches
> through the global name space? Do we have such a one?
>
We do indeed. It is an
On Thursday, May 7, 2020 at 2:45:51 PM UTC+2, kcrisman wrote:
> ... and again many users may not even know there is a directory structure
> at all. This is not a "highly peculiar set of disabilities" - rather, the
> skill set of people on sage-devel is a "highly peculiar set of abilities",
On a related note, that was one of the awesome things about the
(now-deprecated) sagenb. You clicked "Help" and got immediate links to
very relevant Sage-specific help, including for the notebook itself. (Did I
learn about search_def() from that 13 years ago? I don't know any more.)
--
You
On Thursday, May 7, 2020 at 9:17:34 AM UTC-4, Michael Orlitzky wrote:
>
> On 5/7/20 8:45 AM, kcrisman wrote:
> >
> > Again, I think it is not necessarily the case that users of
> > Sage-the-software - say, in a CoCalc-provided notebook as a student -
> > necessarily know how to "search a
On Thursday, May 7, 2020 at 9:58:55 AM UTC-7, John H Palmieri wrote:
>
>
>
> On Thursday, May 7, 2020 at 4:40:52 AM UTC-7, Michael Orlitzky wrote:
>>
>> On 5/6/20 11:28 PM, John H Palmieri wrote:
>> >
>> > And to clarify, this is what you expect users to use instead of
>> > search_src? ;)
On Thursday, May 7, 2020 at 4:40:52 AM UTC-7, Michael Orlitzky wrote:
>
> On 5/6/20 11:28 PM, John H Palmieri wrote:
> >
> > And to clarify, this is what you expect users to use instead of
> > search_src? ;)
> >
>
And to clarify, neither you nor Dima understand ";)"?
> It's an
On 5/7/20 8:45 AM, kcrisman wrote:
>
> Again, I think it is not necessarily the case that users of
> Sage-the-software - say, in a CoCalc-provided notebook as a student -
> necessarily know how to "search a bunch of files for a string" or even
> know that there is such a thing.
Anyone who wants
> A script that we ship to end users has to be portable, which is why that
> command is a mouthful even though most of that syntax has been in "man
> find" forever. But individual users only need something that works on
> their machines. So POSIX trivia aside, "do whatever you would normally
On 5/6/20 11:28 PM, John H Palmieri wrote:
>
> And to clarify, this is what you expect users to use instead of
> search_src? ;)
>
It's an improvement to sage-grep. In another message you said, "It was
reimplemented in Python to make it work across platforms... and to make
it faster." It's not
On Thu, May 7, 2020 at 4:29 AM John H Palmieri wrote:
>
>
>
> On Sunday, May 3, 2020 at 4:48:49 PM UTC-7, Michael Orlitzky wrote:
>>
>> On 5/2/20 1:55 PM, John H Palmieri wrote:
>> >
>> > OMG, why does "sage -grep" use the "find" command?
>> >
>>
>> Others have pointed out that "-r" isn't
On Sunday, May 3, 2020 at 4:48:49 PM UTC-7, Michael Orlitzky wrote:
>
> On 5/2/20 1:55 PM, John H Palmieri wrote:
> >
> > OMG, why does "sage -grep" use the "find" command?
> >
>
> Others have pointed out that "-r" isn't standard, but "-r" is wrong
> anyway. It's only supposed to search
On 5/2/20 1:55 PM, John H Palmieri wrote:
>
> OMG, why does "sage -grep" use the "find" command?
>
Others have pointed out that "-r" isn't standard, but "-r" is wrong
anyway. It's only supposed to search through python files. And having
"find" look for those files isn't any slower than having
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()
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
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
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,
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(),
> 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
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
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
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
>
>
>
> 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
There is a tradeoff. If I want to search the Sage source code, running
"search_src(...)" in Sage is easy, and it's in our documentation, so people
might find it. Running '!grep -R -n ... "$SAGE_ROOT"/src/sage' is not quite
as easy; if you want the line numbers, you need -n, and it also requires
I would be in favour of deprecation and eventual removal of search_src()
just as we discard old implementations of maths functions in favour of
maintained faster implementations in external libraries, we ought to
discard outdated interfaces too.
Dima
On Fri, 1 May 2020, 14:22 Michael Orlitzky,
On 5/1/20 8:45 AM, kcrisman wrote:
>
> I don't know whether python functions can call the ! things but I
> think it would help users to keep search_src(s) as a shorthand for
> !grep -r s $SAGE_ROOT/src and search_def(s) for search_src("def "+s).
>
>
> Thanks for more calmly and
> I don't know whether python functions can call the ! things but I
> think it would help users to keep search_src(s) as a shorthand for
> !grep -r s $SAGE_ROOT/src and search_def(s) for search_src("def "+s).
>
>
Thanks for more calmly and concisely making my point for me.
As for a relevant
On Fri, 1 May 2020 at 13:10, Michael Orlitzky wrote:
>
> On 5/1/20 3:54 AM, John Cremona wrote:
> > I agree with David. I use grep 1000 times a day and I do know how to
> > use a computer (and do not appreciate being patronised)
>
> I'm poking fun at the reasoning behind adding these functions
I agree with David. I use grep 1000 times a day and I do know how to use a
> computer (and do not appreciate being patronised), but I also use
> serach_src() in the middle of Sage sessions a lot and tha seems much more
> useful to me than switching to a different window and navigating to
>
On 5/1/20 3:54 AM, John Cremona wrote:
> I agree with David. I use grep 1000 times a day and I do know how to
> use a computer (and do not appreciate being patronised)
I'm poking fun at the reasoning behind adding these functions to sage,
not the people who use them. I've been on the wrong side
On Fri, May 1, 2020 at 8:54 AM John Cremona wrote:
>
> I agree with David. I use grep 1000 times a day and I do know how to use a
> computer (and do not appreciate being patronised), but I also use
> serach_src() in the middle of Sage sessions a lot and tha seems much more
> useful to me than
I agree with David. I use grep 1000 times a day and I do know how to use a
computer (and do not appreciate being patronised), but I also use
serach_src() in the middle of Sage sessions a lot and tha seems much more
useful to me than switching to a different window and navigating to
wherever
On 4/30/20 3:11 PM, David Roe wrote:
>
> I understand where the criticism is coming from, but I think one of the
> big plusses of search_src and friends is that they're usable from the
> sage command line without switching context to the command line. I
> don't think they should be removed.
On Thu, Apr 30, 2020 at 2:56 PM Michael Orlitzky
wrote:
> On 4/30/20 2:10 PM, John H Palmieri wrote:
>
> >
> > They're doctested, and they still work. What makes the implementation
> > bad? They use standard Python library tools to walk a directory tree and
> > then to do a regexp search on the
On 4/30/20 2:10 PM, John H Palmieri wrote:
>
> They're doctested, and they still work. What makes the implementation
> bad? They use standard Python library tools to walk a directory tree and
> then to do a regexp search on the files there. An advantage to this
> approach is that it is standard
On Thursday, April 30, 2020 at 11:15:31 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Thu, 30 Apr 2020, 19:10 John H Palmieri, > wrote:
>
>>
>>
>> On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>>>
>>> On 4/30/20 11:16 AM, Dima Pasechnik wrote:
>>> >
>>> > I think we
On Thu, 30 Apr 2020, 19:10 John H Palmieri, wrote:
>
>
> On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>>
>> On 4/30/20 11:16 AM, Dima Pasechnik wrote:
>> >
>> > I think we should just remove this completely, as ipython nowadays has
>> > %history magic which certainly
On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>
> On 4/30/20 11:16 AM, Dima Pasechnik wrote:
> >
> > I think we should just remove this completely, as ipython nowadays has
> > %history magic which certainly can do the same as log_text()
> >
>
> +1
>
> I feel the
On 4/30/20 11:16 AM, Dima Pasechnik wrote:
>
> I think we should just remove this completely, as ipython nowadays has
> %history magic which certainly can do the same as log_text()
>
+1
I feel the same way about functions like search_src() that badly
reimplement grep (even if they still work).
the code in src/sage/misc/log.py is quite old, and has no doctests.
As a result it has bitrotted due to an ipytthon update some years ago.
See https://trac.sagemath.org/ticket/29621
I think we should just remove this completely, as ipython nowadays has
%history magic which certainly can do the
49 matches
Mail list logo
