On Sun, Jan 3, 2016 at 1:49 PM, Emmanuel Charpentier
<emanuel.charpent...@gmail.com> wrote:
>
>
> Le dimanche 3 janvier 2016 21:23:56 UTC+1, Volker Braun a écrit :
>>
>> On Sunday, January 3, 2016 at 5:36:30 PM UTC+1, Emmanuel Charpentier
>> wrote:
>>>
>>> [ BTW : that's not really a bug, but rather a design conflict : the
>>> original %mode functions were designed to switch (for an indefinite scope)
>>> the behaviour of the REPL.This was transposed in the Sage notebook as what
>>> amounts to the equivalent of Jupyter's cell magics (scope defined as the
>>> current cell). Whereas line magics are, as far as I understand,
>>> Jupyter-specific... We can't be consistent across notebooks without
>>> redefining our "mode switch" magics as "cell magics", and rename them with
>>> "%%"... ]
>>
>>
>> IMHO we should just switch the interface line magics to work like other
>> line magics in Jupyter/IPython, and also SMC: Take the rest of the line as
>> string and evaluate
>
>
> As stated, that would break the compatibility with SMC magics that William
> just declared intangible (and always "cell magic").
Just to be clear: I don't care whether or not whatever design you
guys are coming up with in this thread is compatible with SMC Sage
worksheets. SMC provides both Sage worksheets and Jupyter notebooks
on an equal footing; each has its pros and cons, and will continue to
be fully supported (likely with a converter between them, that at
least converts what can be converted).
> This could be (more or
> less) restored if the magic function had access to the current interface.
> Pseudo-Python ahead :
>
> args, input=(RestOfTheFirstLline(), RestOfTheCell())
> if(SMC):
> ReturnAndPrint(magicfun(input))
> if(commandline): ## In that case, by definition, input==None
> if(restofthefirstline=""):
> switchREPLuntilEOFOrOtherMagic(magicfun())
> else:
> ReturnAndPrint(magicfun(args))
> else: ## Jupyter
> ProcessOptions(args)
> ReturnAndPrint(magicfun(input, ProcessedOptions))
>
> The difficulty is, of course, that the same part of the command structure
> (the rest of the first line) would mean two different things :
> - source code to execute in a command line
> - possible options to be passed to a cell magic in Jupyter (some interface,
> already supported (rpy2, the IRkernel for R) already use this convention !).
>
> Furthermore, I supposed that SMC ignored the rest of the first line. This is
> what the %r magic does
> %r print(2+2)
> print(3+2)
>
> ## prints [1] 5, even if the pasted result is a bit more complicated :
> ︡3c5a5418-14e0-46fe-a34d-3fa7a0eb1b7d︡︡{"stdout":"[1]
> 4","done":false}︡{"stdout":" 5\n","done":false}︡{"done":true}
> ︠68da460a-f070-4758-9fbb-667f85c4819es︠
>
> but not the %maxima magic :
>
>
> %maxima diff(log(x),x)
> integrate(arctan(x),x)
>
> ## prints 1/x on one line, then x*arctan(x) - 1/2*log(x^2 + 1) on the next
> line, but again the reality is a bit more complicated :
>
> ︡410cbb81-a181-4e01-92a0-0c3e28da800a︡︡{"stdout":"1/x","done":false}︡{"stdout":"\n","done":false}︡{"stdout":"x*arctan(x)
> - 1/2*log(x^2 + 1)\n","done":false}︡{"done":true}
> ︠e820fb8a-cd58-4173-9d99-95dd022e4a6f︠
>
> Therefore, we have a specification/consistency problem, to be solved BEFORE
> the coding problem(s).
>
> We should also specify what happens with the computed results : are they
> just displayed in the output cell and kept in the target interpreterv
> instance ? (In that case, we should be damn sure that we vcan get the
> results back by other means, such as r() after an %r cell, or maxima() after
> a %maxima computation). Or should we try to return something ? If so, how ?
>
> We should also specify how to pass data to the called interpreter, and back
> to Sage. At least in the case of r(), it is hard to get anything else than
> string representations. One point of using %R is that this dat interchange
> problem is at least treated consistently.
>
> Note that the "coding problems" are not that small : ensuring that r(...),
> %r, %R and %%R "speak" to the same instance of R does not seem trivial (at
> least for my midget capacities)...
>>
>>
>>
>> Example for IPython default magic:
>>
>> sage: %system ls Makefile
>> ['Makefile']
>>
>>
>> Example for how we currently handle line magics on the commandline (BAD:
>> we just forget about the argument)
>>
>> sage: %gap 1+1;
>>
>> --> Switching to Gap <--
>>
>> gap: ^C
>>
>> --> Exiting back to Sage <--
>>
>>
>> Expected behavoir of %gap 1+1; is to be like
>>
>> sage: gap('1+1;')
>> 2
>>
>>
>> On the commandline ONLY line magics without arguments could still switch
>> the interface
>
>
> Should we open a ticket for this, or should we continue to discuss the
> specificatin here, opening tickets for the actual coding ?
>
> HTH (but doubting it...),
>
> --
> Emmanuel Charpentier
>
>>
>>
>
> --
> 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 post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
William (http://wstein.org)
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
