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"). 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.
