Hi David, Thanks for the github suggestions. I will do that at some point. Given your pointer in the doc, I now see that the solution to my problem when trying to run a given segment on SymPy Live was to replace '>>>' with '...' when defining a function. It now works as desired.
Comer On Fri, May 2, 2014 at 8:08 PM, David Li <[email protected]> wrote: > Hello Comer, > > You could fork the SymPy project on Github, create a new branch, push the > changes to that branch, and share the URL with us on the mailing list. That > way we can see what you have and comment on it. > > Thank you, > David Li > > > On Fri, May 2, 2014 at 5:06 PM, Comer Duncan <[email protected]>wrote: > >> Hi David, >> >> How can I share my work in progress so you can see better what I am >> seeing? So far the new documentation is a tutorial, i.e. is a file in the >> tutorial subdir. I have not made a new git project, thinking that I would >> like to get the writing further along before submitting a pull request. So >> thus far the work is only in my local machine's doc directory. >> >> Thanks for the comments. >> >> Comer >> >> >> On Fri, May 2, 2014 at 5:54 PM, David Li <[email protected]> wrote: >> >>> Hello, >>> >>> Could you please be more specific about the 'complaint'? If the input >>> method is set to 'enter', then 'shift-enter' will create a newline without >>> submitting the expression. >>> >>> For the second part of your question: as I understand, your >>> documentation contains a function definition, but when 'Run code block in >>> SymPy Live' is pressed, it comes up with an error? In the documentation >>> there are examples of functions being defined that work just fine (e.g. >>> http://docs.sympy.org/latest/tutorial/simplification.html#example-continued-fractions) >>> - perhaps you could see how that example is formatted. Without the error >>> message I'm not quite sure what is wrong. >>> >>> David >>> >>> >>> On Thursday, May 1, 2014 5:13:07 PM UTC-7, Comer wrote: >>>> >>>> Today I tried defining a function while in the SympyLive shell. That >>>> is something like: >>>> >>>> def f(x): >>>> return x >>>> >>>> But when entered, I got a complaint. So I changed the input method to >>>> shift-enter and got it to work (ie got the def to work). When using it with >>>> such as f(1) it returned the correct answer. However, I am now writing >>>> some documentation on my local machine and when it is made it has no >>>> errors. When I view the html of the new stuff I am writing which includes >>>> some example code with a def f(x): >>>> in it, when executed in SymPy Live from the html display of the new >>>> doc, I get a failure just when the new function is defined. So it does not >>>> parse the requested code as I want. It seem that when executing the doc >>>> code on SymPy Live the apparently needed shift-enter rather than the >>>> default enter is what is encountered. So for the unsuspecting user who >>>> reads the documentation and just wants to run it, there is a problem. How >>>> to enable the correct behavior so the user will get the code executed >>>> properly and will not have to discover the workaround. I just want the code >>>> to work with no further bother from the user. Can someone please clue me >>>> in? >>>> >>>> Thanks. >>>> >>>> Comer >>>> >>> >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAEL1xhCueLKuNW%2BnsUUNmEmTMiFxAsQkv7VsHsux6UiJzG7s0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
