Hide input in <sage> and autoeval

[Sz Tengely]

I would like to include some Sage @interact applets using <sage><input></input><output></output></sage>. Is there a way to hide the long input part somehow like in case of a html website:

<script>$(function () {
	            // Make the div with id 'mycell' a Sage cell
	                sagecell.makeSagecell({inputLocation:  '#mycell',
	                template:       sagecell.templates.restricted,
	                evalButtonText: 'Activate'});
	            // Make *any* div with class 'compute' a Sage cell
	                sagecell.makeSagecell({inputLocation: 'div.compute',
	                editor: "textarea-readonly",
	                evalButtonText: 'Compute',
                        autoeval: true,
                        hide: ["editor","evalButton"]});
	                });
	</script>

where hide: ["editor","evalButton"] does the job? Is there a way to have autoevaluation like autoeval: true, instead of pushing an Evaluate(Sage) as provided here: 
http://faculty.sfasu.edu/judsontw/ode/html/systems04.html?

[Thomas Judson]

I would also like to hide input.  As far as I know, this has not yet been implemented.

Tom Judson

--
You received this message because you are subscribed to the Google Groups "PreTeXt support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.
To post to this group, send email to pretext...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/2354e0f8-8106-4ee5-8e4e-8a01b95201f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mitch Keller]

I think that perhaps this is better accomplished by making the tools used to embed other interactive things (Geogebra, Desmos, jsxgraph, etc.) capable of taking SageMath code as input and rendering only the output. That makes clear what the content-based purpose of the code is, rather than essentially trying to control presentation by making something hidden.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/E269C138-907C-42B9-85D9-ED24908E711D%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

—
Mitch Keller
mi...@rellek.net

[Thomas Judson]

Actually, hiding a Sage cell is pretty easy if you are just coding a cell into a web page (see https://github.com/sagemath/sagecell/blob/master/doc/embedding.rst). We already have some options for Sage cells in PTX; e.g., the following code sets the Sage cell language to R:

<sage language="r">
<input>
<![CDATA[ruth <- c(22, 25, 34, 35, 41, 41, 46, 46, 46, 47, 49, 54, 54, 59, 60)
stem(ruth)]]>
</input>
</sage>

Could we just have an option like <sage hide=“True”> with the default being that the cell is visible? That would make it very easy for authors.

Tom

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/D837131E-3CA1-4799-A92F-A8E89188CAAC%40rellek.net.

[Mitch Keller]

I’m not the Keeper of the Language™, but here’s my thoughts:

Setting the language is about the content of that cell. Hiding it is about presentation. I would argue that it’s bad form to hide a cell just to make later cells evaluate nicely without readers needing to see setup code, since otherwise behavior in a cell might not be reproducible if someone copies and pastes code into their own SageMath environment.

If the point is to produce a SageMath interactive on the page but without the code displaying, then it seems that should be handled via a different mechanism that would nicely support producing a static image to include in LaTeX (or other static) output.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/7E517C78-9A9E-4324-8621-3FAEA5DBCD0F%40gmail.com.

[Thomas Judson]

I would argue that it is best to be able to turn hiding off and on. It would keep everything in Sage and debugging interacts might be easier.

Tom

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/51259C3C-8A25-4A5C-B18B-65CF4331328A%40rellek.net.

[Rob Beezer]

I think a Sage interact should go in the new "interactive" element (though I
have not decided exactly how). You would definitely not normally see the code.
The code would be transparent in the PTX source, and probably also in the
PTX-generated HTML. Things like doctesting could, and likely would, be handled
differently. Almost surely "sandboxed" from the rest of the page, the total
opposite of current shared variables. So I agree with Mitch, and it also solves
a lot of practical problems as a result of knowing that the code is an interact.

That said, Tom's example of an R plot of data, could have a monstorous amount of
data backing it, and nobody wants to see all that. And maybe it is more than
just what "sageplot" would buy you. And I don't think the Cell server can read
from a local file like you'd like here. So I see some utility in (selectively)
hiding some cells. Though I swear I tried this once and it "didn't work."

I'll experiment.

Rob

[Rob Beezer]

I've got a small prototype of a Sage cell with an interact in it, which
auto-evaluates and hides itself.

Conceivably we could supply a knowl or something that contains the source code
of the interact, since it would be semi-obscured.

As I chip away at the remaining interactives, I'll see what I can do with this one.

[Karl-Dieter Crisman]

On Wednesday, April 11, 2018 at 6:24:49 PM UTC-4, Rob Beezer wrote:

I've got a small prototype of a Sage cell with an interact in it, which
auto-evaluates and hides itself.

That would be pretty useful, especially for interactives for discovery where you only want the interaction since the code would make it "obvious" what the pattern is.

[Rob Beezer]

Thanks, KDC. While I have you on the line: I've been "sandboxing" most of the
interactives within iframes. How would your work be affected if each
interactive is isolated from the rest of the page, and can't "see" results from
other cells on the page? Can you see any long-range downside to that?

Note that it would be easy to use "xi:include" to effectively "import" (not in
the Python sense) a single common file of function definitions for use with more
than one Sage interact.

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-suppo...@googlegroups.com

> <mailto:pretext-suppo...@googlegroups.com>.

> To post to this group, send email to pretext...@googlegroups.com

> <mailto:pretext...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-support/4edfa4a8-f38c-4b35-99f8-931e4b55e34d%40googlegroups.com
> <https://groups.google.com/d/msgid/pretext-support/4edfa4a8-f38c-4b35-99f8-931e4b55e34d%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Karl-Dieter Crisman]

On Thursday, April 12, 2018 at 9:07:44 PM UTC-4, Rob Beezer wrote:

Thanks, KDC.  While I have you on the line: I've been "sandboxing" most of the
interactives within iframes.  How would your work be affected if each
interactive is isolated from the rest of the page, and can't "see" results from
other cells on the page?  Can you see any long-range downside to that?

Hmm, for me that would probably cause at least some problems - as you say, I often have people define a few functions at the top of the page.  At least I think that is how I've worked it, e.g. in the cryptography sections.  So it would be pretty inconvenient to have to define those in each *cell*, if that's what you mean. 

[Rob Beezer]

Well, it would mean building a file of ancillary functions, and then
xi:include'ing it as part of the code for each interact (one line per). And
existing interact's would continue to run as-is, you would not have any deadline
to move them.

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-suppo...@googlegroups.com
> <mailto:pretext-suppo...@googlegroups.com>.
> To post to this group, send email to pretext...@googlegroups.com
> <mailto:pretext...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-support/b41628c9-fee8-4c04-be3e-368f0396cd09%40googlegroups.com
> <https://groups.google.com/d/msgid/pretext-support/b41628c9-fee8-4c04-be3e-368f0396cd09%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rob Beezer]

I think I remember the problem now.

Sage Cell configuration is on a per-CSS-selector basis.

So hiding, auto-evaluating, and linking all get configured together. Thus, if
you hide one cell, and want to use previous results, or make its results
available to later cells, you will have those linked cells hidden as well.

A configuration like this should work well for a one-shot Sage interact. When I
do that work, I'll see if there is a way around this, but I'm not optimistic.

A feature request on the "sage-cell" Google Group might be the best avenue right
now.

Rob