On Thu, Feb 12, 2009 at 10:13 PM, Robert Bradshaw
wrote:
>
> On Feb 10, 2009, at 11:44 PM, Simon King wrote:
>
>> An alternative idea:
>> FOO.X --> all attributes starting with X
>> FOO.X (press TAB twice) --> all attributes containing X
>>
>> Perhaps this is easier to implement.
>
> I actual
On Feb 10, 2009, at 11:44 PM, Simon King wrote:
>
> On Feb 10, 11:58 am, "Nicolas M. Thiery"
> wrote:
> ...
>> One advantage is that this should require no change in the sage
>> interfaces. In particular, this does not require playing with special
>> inputs like Shift-TAB, which can be messy in
On Tue, Feb 10, 2009 at 11:50 PM, Simon King
wrote:
>
> Dear William,
>
> slightly OT:
>
> On Feb 10, 4:25 pm, William Stein wrote:
> ...
>> On Tue, Feb 10, 2009 at 7:18 AM, Simon King
>> wrote:
>> > It concerns multivariate factorization. I had p.factor() in my code,
>> > but at some point I
Dear William,
slightly OT:
On Feb 10, 4:25 pm, William Stein wrote:
...
> On Tue, Feb 10, 2009 at 7:18 AM, Simon King
> wrote:
> > It concerns multivariate factorization. I had p.factor() in my code,
> > but at some point I got a NotImplementedError. As Martin pointed out,
> > it is due to a
On Feb 10, 11:58 am, "Nicolas M. Thiery"
wrote:
...
> One advantage is that this should require no change in the sage
> interfaces. In particular, this does not require playing with special
> inputs like Shift-TAB, which can be messy in terminals.
Right, I didn't realize that Shift-TAB may have
On Feb 10, 2009, at 2:58 AM, Nicolas M. Thiery wrote:
>
On Feb 9, 2009, at 11:34 PM, Simon King wrote:
> Yes!
> I could imagine:
> 1. FOO.X searches for attributes that start with X (current
> behaviour)
> 2. FOO.X searches for attributes that *contain* X (new
> fea
> >> On Feb 9, 2009, at 11:34 PM, Simon King wrote:
> >>> Yes!
> >>> I could imagine:
> >>> 1. FOO.X searches for attributes that start with X (current
> >>> behaviour)
> >>> 2. FOO.X searches for attributes that *contain* X (new
> >>> feature)
+1 as well
And a big +1 in general for this discu
Stan Schymanski wrote:
> Hi Jason,
>
> Could you post a link to a description of how to use TB as a "proper"
> newsreader to access Google Groups? I only found this:
> http://forums.mozillazine.org/viewtopic.php?f=30&t=636724
>
Set up a new newsgroup account in Thunderbird. The server will b
On Tue, Feb 10, 2009 at 7:38 AM, Carl Witty wrote:
>
> On Tue, Feb 10, 2009 at 7:22 AM, Carl Witty wrote:
>> On Mon, Feb 9, 2009 at 11:34 PM, Simon King
>> wrote:
>>>
>>> Hi!
>>>
>>> On Feb 9, 11:46 pm, john_perry_usm wrote:
What if there were a different trigger for the extended complet
On Tue, Feb 10, 2009 at 7:22 AM, Carl Witty wrote:
> On Mon, Feb 9, 2009 at 11:34 PM, Simon King
> wrote:
>>
>> Hi!
>>
>> On Feb 9, 11:46 pm, john_perry_usm wrote:
>>> What if there were a different trigger for the extended completions?
>>> This way the user would have only one box to parse at
Hi Jason,
Could you post a link to a description of how to use TB as a "proper"
newsreader to access Google Groups? I only found this:
http://forums.mozillazine.org/viewtopic.php?f=30&t=636724
Not sure how to move this to the "recent unanswered sage-support posts"
discussion on sage-support.
On Tue, Feb 10, 2009 at 7:18 AM, Simon King wrote:
>
> Dear William,
>
> On Feb 10, 2:48 pm, William Stein wrote:
>> You have been using Sage for about a year now, or more. In your
>> opinion, how are we doing so far regarding breaking or not breaking
>> *your* code with each new release of Sag
boot...@u.washington.edu wrote:
>
>
>
> On Tue, 10 Feb 2009, Franco Saliola wrote:
>
>> On Tue, Feb 10, 2009 at 8:49 AM, Robert Bradshaw
>> wrote:
>>> On Feb 9, 2009, at 11:34 PM, Simon King wrote:
>>>
Yes!
I could imagine:
1. FOO.X searches for attributes that start with X (c
On Feb 10, 7:16 am, Jason Grout wrote:
> mabshoff wrote:
> > Well, there are enough people around that if you remove right_kernel()
> > or whatever will end up with broken code. Having it deprecated for a
> > year or two seems to have zero cost to me.
>
> While this thread has gone off into
On Mon, Feb 9, 2009 at 11:34 PM, Simon King wrote:
>
> Hi!
>
> On Feb 9, 11:46 pm, john_perry_usm wrote:
>> What if there were a different trigger for the extended completions?
>> This way the user would have only one box to parse at a time.
>
> Yes!
> I could imagine:
> 1. FOO.X searches for a
Stan Schymanski wrote:
> I have, but unfortunately, only for messages I've been interested in
> myself, otherwise I don't notice them. Since it is not possible to
> automatically highlight unanswered messages, we could encourage people
> in the guidelines to repeat their unanswered questions.
Dear William,
On Feb 10, 2:48 pm, William Stein wrote:
> You have been using Sage for about a year now, or more. In your
> opinion, how are we doing so far regarding breaking or not breaking
> *your* code with each new release of Sage? When your code does break,
> how responsive have we been.
mabshoff wrote:
>
>
> On Feb 10, 2:02 am, Martin Albrecht
> wrote:
>
> Hi,
>
>>> We should never intentionally break people's code like that if there
>>> is no pressing issue. Adding deprecation warnings is ok to point
>>> people in the right direction, but from discussions about this at SD12
I have, but unfortunately, only for messages I've been interested in
myself, otherwise I don't notice them. Since it is not possible to
automatically highlight unanswered messages, we could encourage people
in the guidelines to repeat their unanswered questions.
William Stein wrote:
> On Tue,
Franco Saliola wrote:
> On Tue, Feb 10, 2009 at 8:49 AM, Robert Bradshaw
> wrote:
>> On Feb 9, 2009, at 11:34 PM, Simon King wrote:
>>
>>> Yes!
>>> I could imagine:
>>> 1. FOO.X searches for attributes that start with X (current
>>> behaviour)
>>> 2. FOO.X searches for attributes that *contain*
On Feb 10, 6:12 am, Stan Schymanski wrote:
> William Stein wrote:
Hi Stan,
>. Maybe it
> would be good to somehow keep unanswered emails at the top of list. Not
> sure if this is possible in Google Groups.
I am not aware of any mechanism that would let you do that in Google
grops. You can ch
On Tue, Feb 10, 2009 at 6:12 AM, Stan Schymanski wrote:
> In general, I find the response to any of my problems on sage-support or
> sage-devel incredibly fast and helpful. There are a few that passed
> below the radars, though. I thought this had something to do with the
> query itself, but sinc
William Stein wrote:
>
> You have been using Sage for about a year now, or more. In your
> opinion, how are we doing so far regarding breaking or not breaking
> *your* code with each new release of Sage? When your code does break,
> how responsive have we been.
>
The only time I can remember
On Tue, Feb 10, 2009 at 4:57 AM, Stan Schymanski wrote:
>
> +1 for maintaining backwards compatibility as much as practically possible.
>
> Mathematica 5.2, probably considered a mature program, was upgraded to
> Mathematica 6.0 and broke most of my code. This gave me the final
> incentive to loo
On Feb 10, 5:18 am, mhampton wrote:
> I think its hard to get a one-size-fits-all policy here. I am
> thinking specifically of the polytope code in polyhedra.py - I am very
> happy with the progress so far, but its still young code that has bugs
> and some architectural issues. In the last fe
I think its hard to get a one-size-fits-all policy here. I am
thinking specifically of the polytope code in polyhedra.py - I am very
happy with the progress so far, but its still young code that has bugs
and some architectural issues. In the last few months more people
have started looking at it
On Feb 10, 4:45 am, Martin Albrecht
wrote:
Hi Martin,
> > > Think about e.g. the planed break up of gen.pyx into elements that make
> > > sense.
>
> > Sure, but that will happen transparently without any impact to the
> > user's code.
>
> I am pretty sure it will have an impact on user's code
+1 for maintaining backwards compatibility as much as practically possible.
Mathematica 5.2, probably considered a mature program, was upgraded to
Mathematica 6.0 and broke most of my code. This gave me the final
incentive to look for alternatives as I would have to spend hours and
hours to fi
> > Think about e.g. the planed break up of gen.pyx into elements that make
> > sense.
>
> Sure, but that will happen transparently without any impact to the
> user's code.
I am pretty sure it will have an impact on user's code because it is supposed
to clean up the mess that is gen.pyx. Maintai
On Feb 10, 4:08 am, Martin Albrecht
wrote:
Hi Martin,
> > > It seems to me: Sage isn't done yet and pretending it was does more harm
> > > than good by making it more difficult to contribute.
>
> > Why? Can you make a concrete example at what you are driving at?
> > Methods with underscore ar
> > It seems to me: Sage isn't done yet and pretending it was does more harm
> > than good by making it more difficult to contribute.
>
> Why? Can you make a concrete example at what you are driving at?
> Methods with underscore are exempted from the deprecation rule since
> those are internal, bu
On Feb 10, 2:02 am, Martin Albrecht
wrote:
Hi,
> > We should never intentionally break people's code like that if there
> > is no pressing issue. Adding deprecation warnings is ok to point
> > people in the right direction, but from discussions about this at SD12
> > and in other places it ha
> We should never intentionally break people's code like that if there
> is no pressing issue. Adding deprecation warnings is ok to point
> people in the right direction, but from discussions about this at SD12
> and in other places it has become clear at least to me that six months
> is not even
On Tue, 10 Feb 2009, Franco Saliola wrote:
>
> On Tue, Feb 10, 2009 at 8:49 AM, Robert Bradshaw
> wrote:
>>
>> On Feb 9, 2009, at 11:34 PM, Simon King wrote:
>>
>>> Yes!
>>> I could imagine:
>>> 1. FOO.X searches for attributes that start with X (current
>>> behaviour)
>>> 2. FOO.X searches
On Tue, Feb 10, 2009 at 8:49 AM, Robert Bradshaw
wrote:
>
> On Feb 9, 2009, at 11:34 PM, Simon King wrote:
>
>> Yes!
>> I could imagine:
>> 1. FOO.X searches for attributes that start with X (current
>> behaviour)
>> 2. FOO.X searches for attributes that *contain* X (new
>> feature)
+1! For ex
On Feb 9, 2009, at 11:34 PM, Simon King wrote:
> Hi!
>
> On Feb 9, 11:46 pm, john_perry_usm wrote:
>> What if there were a different trigger for the extended completions?
>> This way the user would have only one box to parse at a time.
>
> Yes!
> I could imagine:
> 1. FOO.X searches for attribu
Hi!
On Feb 9, 11:46 pm, john_perry_usm wrote:
> What if there were a different trigger for the extended completions?
> This way the user would have only one box to parse at a time.
Yes!
I could imagine:
1. FOO.X searches for attributes that start with X (current
behaviour)
2. FOO.X searches f
What if there were a different trigger for the extended completions?
This way the user would have only one box to parse at a time.
john perry
On Feb 9, 9:44 am, Jason Grout wrote:
> Hi all,
>
> Currently, anytime there is a command that contains a noun and an
> adjective, there seems to be deba
> This is a bit arbitrary for my tastes, but I think it (or somthing
> similar) could work:
>
> If you type foo.X, where X is only one or two characters, then
> the extended completion list checks for *_X*. Otherwise (if X is
> three or more characters) then the extended completion list is *X*.
On Feb 9, 10:39 am, mhampton wrote:
> I think this is a great idea. It might not solve the problem of
> clutter immediately, because if something like eigenvectors_right is
> removed it would break a lot of existing code. But perhaps we could
> remove such things in 4.0 after adding deprecati
On Feb 9, 8:44 am, Jason Grout wrote:
> What do people think? I think this would finally answer the tension
> between the people that want useful tab completion and the people who
> want the function names to look "right".
FWIW I 'm pretty sure aliases are a disaster; whether you
can get most
On Mon, Feb 9, 2009 at 11:05 AM, Jason Grout
wrote:
>
> Carl Witty wrote:
>> And maybe the second list should be omitted altogether if it's too
>> big? For instance, if I type foo.e, I'm probably not interested
>> in the list of all method names that include an 'e' somewhere.
>
> Yes, but I'm no
Carl Witty wrote:
> On Mon, Feb 9, 2009 at 7:44 AM, Jason Grout
> wrote:
>> What if, at least for the notebook, and maybe for the command line too,
>> we listed two sets of completions: the first would be the list given
>> now, and the second would be the list given above?
>
> +1 for extending
I think this is a great idea. It might not solve the problem of
clutter immediately, because if something like eigenvectors_right is
removed it would break a lot of existing code. But perhaps we could
remove such things in 4.0 after adding deprecation warnings.
-Marshall
On Feb 9, 5:44 pm, Jas
On Mon, Feb 9, 2009 at 7:44 AM, Jason Grout wrote:
> What if, at least for the notebook, and maybe for the command line too,
> we listed two sets of completions: the first would be the list given
> now, and the second would be the list given above?
+1 for extending tab-completion to mention thes
+1 to both commandline and notebook
On Mon, Feb 9, 2009 at 11:55 AM, wrote:
>
> +1!
>
>
> On Mon, 9 Feb 2009, Jason Grout wrote:
>
>>
>> Hi all,
>>
>> Currently, anytime there is a command that contains a noun and an
>> adjective, there seems to be debate about what order they should be
>> list
+1!
On Mon, 9 Feb 2009, Jason Grout wrote:
>
> Hi all,
>
> Currently, anytime there is a command that contains a noun and an
> adjective, there seems to be debate about what order they should be
> listed. For example, there have been debates over whether to name a
> function right_eigenvectors
+1 for the command line.
Currently to find all the plot commands is not as easy as it should be IMHO
On Mon, Feb 9, 2009 at 10:44 AM, Jason Grout
wrote:
>
> Hi all,
>
> Currently, anytime there is a command that contains a noun and an
> adjective, there seems to be debate about what order they
> In other words, if
> in the notebook, you typed m.eigenvectors, you would get a box
> containing two lists:
> ___
> | |
> | list of current completions|
> | |
> |-
49 matches
Mail list logo
