"Jupyter" VPython without a Jupyter notebook

[Bruce Sherwood]

There are still some bugs, but we expect to release soon an installer for full Python that in addition to running VPython in a Jupyter notebook can also run VPython from IDLE or a command line, without involving a Jupyter notebook. This addresses the needs of those who want to use VPython with full Python capabilities (which is not possible in GlowScript VPython) but who don't wish to use the Jupyter environment. At least initially, this modality will not work with Python 2.7.

Here's how it works: In the Jupyter notebook case, the notebook machinery does most of the server work of handling communications between a VPython program and the browser. When running without the notebook, we use our own server code, using the Python modules webserver and http.server for setting up the client program in the browser and sending libraries, images, and fonts to the browser, and using the Python module autobahn.asyncio.websocket to establish high-speed two-way communications to create or modify VPython objects and to handle events. This means that the new VPython installer will need to install autobahn, which is apparently available in Python 3.4 and later but not in Python 2.7.

It is sometimes important to be able to distinguish between Classic VPython, GlowScript VPython, Jupyter VPython, and Trinket VPython, even though the latter three versions share the same syntax for 3D objects. How shall we refer to the new non-notebook VPython version? I admit to having no good suggestions for a name and invite you to suggest one. Thanks!

Bruce

[Bruce Sherwood]

I thought there was a chance at supporting this new modality in Python 2.7 because I heard that there was a module named trollius that provided asyncio functionality for Python 2.7. However, trollius has been officially abandoned by its creator (http://trollius.readthedocs.io), so it seems very likely that the only way to use an up-to-date VPython with Python 2.7 will continue to be in a Jupyter notebook.

[Aaron Titus]

Here are some ideas for a name:

— Terminal VPython or Term VPython

— Standalone VPython

— Offline VPython

This last idea is similar to Plotly. Their package is called Offline Plotly and one imports plotly.offline.

https://plot.ly/python/offline/

AT

--
You received this message because you are subscribed to the Google Groups "VPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vpython-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Spicklemire]

I was thinking “Standalone” sounded good. So +1 for that.

Before this gets out of hand however I’m wondering it might be worth stepping back and looking at the situation at a higher level.

It seems like we have two fundamentally separate issues:

1) Which implementation of Python is being used and 2) How is the OpenGL frame hosted.

It might help to use a naming convention that reflected these underlying aspects

0) Classic VPyton (pre6) uses the CPython interpreter + platform dependent GUI? to host

1) Classic VPython (v6) uses the CPython interpreter + WxWindows to host the display

2) Glowscript using Javascript translation + WebGL hosted on Google App Engine (GAE)

3) Trinket is a think UI wrapper around Glowscript.

4) Jupyter VPython uses the CPython interpreter (in the kernel) + a websocket connection to the browser

5) This new concept uses the CPython interpreter (on the command line or IDLE) + a websocket connection.

It seems to me one could do worse than to call:

0,1 Classic (pre6, 6), or (wx, native)
2,3 Glowscript (GAE, Trinket)
4,5 Websocket (Jupyter, Standalone)

The primary issue is the "high level” design strategy, Classic, Glowscript, Websocket.

The specifics (wx/native, GAE/Trinket, Jupyter/Standalone) are a bit more “in the weeds” though they do matter when it comes to actually do anything.

So maybe Websocket/Jupyter, Websocket/Standalone. If more websocket options grow in the future, they could fit in such a structure.

Does that spur any thoughts?

-steve

[Robert A. Knop Jr.]

On Sun, Apr 23, 2017 at 07:45:17PM -0700, Bruce Sherwood wrote:
> When running without the notebook, we use our own server code, using
> the Python modules webserver and http.server for setting up the client
> program in the browser and sending libraries, images, and fonts to the
> browser, and using the Python module autobahn.asyncio.websocket to
> establish high-speed two-way communications to create or modify
> VPython objects and to handle events.

What is the high-speed communications *with*? Do you still need a
browser open for the display? That is, instead of embedding the display
in a wxWidgets window, it will now be embedded inside a browser
(Firefox, Chrome, etc.)?

Personally, I think that moving on to Python 3.4 isn't a bad thing.
Except for wxWidgets, most of the rest of the world seems to have moved
on to Python 3.

Ideally, I still would like to be free of entanglements with web
browsers, but I know that's not in the cards.

-Rob

--
--Rob Knop
E-mail: rk...@pobox.com
Home Page: http://www.pobox.com/~rknop/
Blog: http://www.galacticinteractions.org/

[Bruce Sherwood]

I don't think Standalone or Offline works, because the existing Jupyter notebook version can run standalone/offline. And even GlowScript Vpython can be run standalone/offline, using the Google App Engine launcher.

It's true that both the Jupyter notebook version and the new scheme use websockets, but that's an implementation detail, not something descriptive of what it looks and feels like when you're using it. Maybe Jupyter VPython should be renamed Notebook VPython, in which case the new scheme maybe could be called something like Standard VPython.

Keep dreaming up suitable names! And feel free to argue against my comments.

Just as Classic VPython opens a window (a wxWidgets window), so also the new mechanism opens a window (a browser window); you don't need to start the browser yourself. The functionality is really about the same -- it's just that the frames of the two kinds of windows look different. Not clear to me that this represents "entanglements with web browsers" any more than using Classic VPython represents "entanglements with wxWidgets" windows. The only real difference is that browsers are enormously more heavily supported than wxWidgets.

[Steve Spicklemire]

I’m thinking of ‘standalone’ in the sense that you can execute a program from the command line and the browser window opens as needed, similar to the wxWindows experience, rather than having to launch a notebook session *first* and then load a notebook, or run GAE and then point a browser to the locally running server. In this sense it’s a ‘standalone’ *experience* even though neither actually require an internet connection. It also feels like more “lightweight” implementation with fewer dependencies than the jupyter notebook implementation (by some metric of the number of things I need to install before it works, or something).

Anyway, my thinking, even if it’s not right. ;-)

-steve

[Bruce Sherwood]

I see your point, and I definitely share your characterization of this modality as feeling "lightweight" compared to the Jupyter environment. "VPython lite"?

Bruce

[Robert A. Knop Jr.]

On Mon, Apr 24, 2017 at 12:29:45PM -0400, Bruce Sherwood wrote:
> Just as Classic VPython opens a window (a wxWidgets window), so also the
> new mechanism opens a window (a browser window); you don't need to start
> the browser yourself. The functionality is really about the same -- it's
> just that the frames of the two kinds of windows look different. Not clear
> to me that this represents "entanglements with web browsers" any more than
> using Classic VPython represents "entanglements with wxWidgets" windows.
> The only real difference is that browsers are enormously more heavily
> supported than wxWidgets.

Oh, interesting. These browser windows are part of the library? I was
thinking that what the library did was open up a connection to a running
Firefox (say) and display there.

If it really is just a standalone browser window that supports WebGL,
then I wouldn't call that entanglements to browsers. (My issue is that
Firefox and Chrome tend to be terrible resource pigs; they're also
really awful operating systems.)

[Bruce Sherwood]

No, the package doesn't include a browser; it invokes whatever browser is your default. I wasn't aware of severe resource problems with Firefox or Chrome. In my own work I've been thrilled that Chrome's JavaScript compiler keeps generating ever faster code. Just a few weeks ago performance on one of my GlowScript VPython benchmarks nearly doubled in speed overnight on Chrome, without me doing anything. I've also noticed that GlowScript VPython (compiled by RapydScript-NG to JavaScript) runs several times faster than the same code in CPython.

[Kevin Karplus]

Chrome does run JavaScript rapidly.  The problem is that it runs a lot of javaScript in windows that really shouldn't be doing anything.  It also frequently gets wedged and needs to be killed and restarted.  Firefox has the same problem---both browsers want to be the only thing running on your computer and hog both CPU and memory resources.

Kevin Karplus   kar...@soe.ucsc.edu    http://www.soe.ucsc.edu/~karplus
Professor of Biomolecular Engineering, University of California, Santa Cruz

Undergraduate Director, Bioinformatics

Program Chair and Undergraduate Director, Bioengineering

​Author of Applied Electronics for Bioengineers​

Affiliations for identification only.

On Mon, Apr 24, 2017 at 1:49 PM, Bruce Sherwood <bruce.s...@gmail.com> wrote:

No, the package doesn't include a browser; it invokes whatever browser is your default. I wasn't aware of severe resource problems with Firefox or Chrome. In my own work I've been thrilled that Chrome's JavaScript compiler keeps generating ever faster code. Just a few weeks ago performance on one of my GlowScript VPython benchmarks nearly doubled in speed overnight on Chrome, without me doing anything. I've also noticed that GlowScript VPython (compiled by RapydScript-NG to JavaScript) runs several times faster than the same code in CPython.

--

You received this message because you are subscribed to the Google Groups "VPython-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vpython-users+unsubscribe@googlegroups.com.

[Robert A. Knop Jr.]

On Mon, Apr 24, 2017 at 02:04:15PM -0700, Kevin Karplus wrote:
> Chrome does run JavaScript rapidly. The problem is that it runs a lot of
> javaScript in windows that really shouldn't be doing anything. It also
> frequently gets wedged and needs to be killed and restarted. Firefox has
> the same problem---both browsers want to be the only thing running on your
> computer and hog both CPU and memory resources.

Yeah, exactly this. Browsers are big ugly lumbering beasts nowadays,
and more and more things happen in, or only in, the browsers. And, my
experience is that they generally are not as responsive or effetive as
the out-of-browser equivalents. (E.g. Liberoffice spreadsheets are more
responsive and less frustrating than Google sheet, etc.)

-Rob

[Bruce Sherwood]

A huge advantage of using a browser as part of an application is that displays and event handling work on all platforms, including mobile devices.

[Bruce Sherwood]

Here's a different idea about names. The Python math module doesn't have two names, Jupyter math or non-Jupyter math; it's just math. So we could and should use the same name for the Python vpython library whether using a notebook or not. It's up to the vpython module to determine whether it's being used in a notebook or not. Steve suggested "websocket VPython". Another possibility would simply be "VPython". Then the names would be these:

"Classic VPython" is invoked with the name "visual".

"VPython" is invoked in a CPython program with the name "vpython" (when necessary, one could say something like "VPython in a notebook" or "VPython without a notebook").

"GlowScript VPython" whose main use is at glowscript.org, hence the name; compiled programs can be exported to web pages; Trinket provides an alternative user interface, as Steve points out.

[Doug Blank]

On Sun, Apr 23, 2017 at 10:45 PM, Bruce Sherwood <bruce.s...@gmail.com> wrote:

There are still some bugs, but we expect to release soon an installer for full Python that in addition to running VPython in a Jupyter notebook can also run VPython from IDLE or a command line, without involving a Jupyter notebook. This addresses the needs of those who want to use VPython with full Python capabilities (which is not possible in GlowScript VPython) but who don't wish to use the Jupyter environment. At least initially, this modality will not work with Python 2.7.

Here's how it works: In the Jupyter notebook case, the notebook machinery does most of the server work of handling communications between a VPython program and the browser. When running without the notebook, we use our own server code, using the Python modules webserver and http.server for setting up the client program in the browser and sending libraries, images, and fonts to the browser, and using the Python module autobahn.asyncio.websocket to establish high-speed two-way communications to create or modify VPython objects and to handle events. This means that the new VPython installer will need to install autobahn, which is apparently available in Python 3.4 and later but not in Python 2.7.

Bruce,

Can you explain a bit about the motivation for this new version? Was it that you needed faster communication between the frontend and the backend? Does this new version use the webbrowser as the graphical window for displaying VPython 3D graphics?

I'll note for others just to clarify: Jupyter is more than just the notebook; it is a client/server architecture. There is a console interface, a Qt interface, and the upcoming JupyterLab interface [1] that combines a real IDE with a variety of tools (including shared multiple user editing, like sagemath already has). I wonder if the need for your new version is a limitation in the client-server architecture, or something else?

Thanks!

-Doug

 

[1] - http://blog.jupyter.org/2016/07/14/jupyter-lab-alpha/

It is sometimes important to be able to distinguish between Classic VPython, GlowScript VPython, Jupyter VPython, and Trinket VPython, even though the latter three versions share the same syntax for 3D objects. How shall we refer to the new non-notebook VPython version? I admit to having no good suggestions for a name and invite you to suggest one. Thanks!

Bruce

[Bruce Sherwood]

The key issue is that some Python users, for whatever their reasons, have expressed a desire to be able to use VPython without having to work in the Jupyter notebook environment. Obviously Jupyter is widely popular but not universally so. Some people prefer a lighter-weight environment, or whatever IDE environment they happen to prefer.

As I've said, the new version uses a web browser for the display, just as in the GlowScript environment.

[Samuel Teixeira Santos]

Hi all.

I love this idea, and I expect a lot for this new version of VPython.

So... why don't just name it as the next version. I mean, the last version of VPython was 6, why not just name it as VPython 7?

Hope see this version soon. Congratulations for all your effort

'Til next.

​

[Bruce Sherwood]

Something like that might indeed make sense, but the numbering should follow the numbering of the pip installers, so the current VPython would be called "VPython 2.0.8". Because there are significant differences between the current VPython syntax and capabilities and VPython 6 and earlier, I continue to favor referring to the older VPython as "Classic VPython".

[Doug Blank]

On Tue, Apr 25, 2017 at 9:11 AM, Bruce Sherwood <bruce.s...@gmail.com> wrote:

The key issue is that some Python users, for whatever their reasons, have expressed a desire to be able to use VPython without having to work in the Jupyter notebook environment. Obviously Jupyter is widely popular but not universally so. Some people prefer a lighter-weight environment, or whatever IDE environment they happen to prefer.

As I've said, the new version uses a web browser for the display, just as in the GlowScript environment.

So between the two newer CPython versions, one runs in Jupyter (including the notebook) and the other uses the browser for display? Are all of the commands and syntax the same?

You could perhaps reduce the confusion by automatically detecting if you are running inside Jupyter, and so collapsing these two versions into one. Or is it more complex than that?

-Doug

[Bruce Sherwood]

I detect whether you're running with or without a notebook and act accordingly. The VPython commands and syntax are exactly the same. All you will need to do is import vpython, and it won't matter whether you're running in a notebook or running from IDLE or running from a command line. 

The name could be "VPython 2.0.8" and if it were for some reason important to say whether you were running in a notebook or not, you'd have to say so. The same VPython commands and syntax also work in GlowScript VPython, though the "Python" there is actually the RapydScript-NG Python-to-JavaScript transpiler.

[Bruce Sherwood]

By extension of this numbering scheme, we could say "VPython 6" instead of "Classic VPython", although the new versoin numbers such as 2.0.8 will be less than 6 for quite a long time.

[Matt Craig]

I'd favor not giving this version a new name. The code base of this and Jupyter VPython is essentially identical. 

I'd just call the whole thing VPython and indicate in the documentation that code can be run either in the classic way or embedded in a Jupyter notebook, and that the goal is code that can be copied/pasted into glowscript.org (with some caveats, since glowscript.org can't see any imported modules).

As far as numbering goes, there is no reason we couldn't make a big jump from 2.0.8 to 7.0, thereby resolving any ambiguity as to what the most recent version is.

 I wonder if the need for your new version is a limitation in the client-server architecture, or something else?

To second what Bruce said, at SciPy last year there was considerable interest in a package called pyglet-helper that implemented part of classic vpython using pyglet as the library for OpenGL. Some of those users really seemed to want something that wasn't tied to Jupyter. Many of those users don't find glowscript.org useful, of course, because you can't tap into the broad array of python packages.

Matt Craig

[Bruce Sherwood]

VPython 7.0 has a nice ring to it!

Bruce